44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# Kubernetes / GKE
|
|
|
|
This Gitea instance is currently hosted on Google Kubernetes Engine.
|
|
|
|
## Apply changes to resources
|
|
|
|
```
|
|
kubectl apply -f gitea-db.yaml
|
|
kubectl apply -f gitea-server.yaml
|
|
```
|
|
|
|
## Write the secrets to the local filesystem
|
|
|
|
```
|
|
./script/get_secrets
|
|
```
|
|
|
|
It writes the secrets (currently the app.ini file, as well as auto-generated
|
|
TLS certificates that are only used when no Let's Encrypt cert is available)
|
|
to the `kubernetes/config/` folder. These files are not in Git because they
|
|
contain credentials.
|
|
|
|
Once you have edited them locally, you need to delete the secrets stored on
|
|
Kubernetes before uploading them again. This is done by this script:
|
|
|
|
```
|
|
./script/replace_secrets
|
|
```
|
|
|
|
## Reuse a released persistent volume:
|
|
|
|
> When you delete a PVC, corresponding PV becomes `Released`. This PV can contain sensitive data (say credit card numbers) and therefore nobody can ever bind to it, even if it is a PVC with the same name and in the same namespace as the previous one - who knows who's trying to steal the data!
|
|
>
|
|
> Admin intervention is required here. He has two options:
|
|
>
|
|
> * Make the PV available to everybody - delete `PV.Spec.ClaimRef`, Such PV can bound to any PVC (assuming that capacity, access mode and selectors match)
|
|
>
|
|
> * Make the PV available to a specific PVC - pre-fill `PV.Spec.ClaimRef` with a pointer to a PVC. Leave the `PV.Spec.ClaimRef,UID` empty, as the PVC does not to need exist at this point and you don't know PVC's UID. This PV can be bound only to the specified PVC.
|
|
>
|
|
>
|
|
> @whitecolor, in your case you should be fine by clearing `PV.Spec.ClaimRef.UID` in the PV. Only the re-created PVC (with any UID) can then use the PV. And it's your responsibility that only the right person can craft appropriate PVC so nobody can steal your data.
|
|
|
|
https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616
|