Согласно документации :
Секреты могут быть смонтированы как тома данных или могут быть представлены как переменные среды для использования контейнером в модуле.
Это пример модуля, который монтирует секрет в томе:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
Установленные секреты обновляются автоматически
Когда секрет, уже использованный в томе, обновляется, спроецированные ключи в конечном итоге также обновляются. Kubelet проверяет, является ли установленный секрет свежим при каждой периодической синхронизации. Тем не менее, он использует свой локальный кеш для получения текущего значения секрета. Тип кэша настраивается с помощью поля (ConfigMapAndSecretChangeDetectionStrategy в структуре KubeletConfiguration). Его можно распространять с помощью watch (по умолчанию), на основе ttl или просто перенаправляя все запросы непосредственно на kube-apiserver. В результате общая задержка с момента обновления Секрета до момента, когда новые ключи проецируются на Pod, может составлять период синхронизации kubelet + задержка распространения кэша, где задержка распространения кэша зависит от выбранного типа кэша ( это равняется просмотру задержки распространения, ttl кеша или нуля соответственно).
Примечание. Контейнер, использующий Secret в качестве монтируемого тома subPath, не будет получать секретные обновления.
Это пример модуля, который использует секреты от переменных среды:
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
restartPolicy: Never
В обоих случаях вам необходимо изменить спецификацию модуля. Вы можете сделать это, отредактировав Pod или Deployment с помощью kubectl edit:
$ kubectl edit pod <pod_name> -n <namespace_name>
$ kubectl edit deployment <deployment_name> -n <namespace_name>
В качестве альтернативы вы можете внести изменения в файл YAML и применить его:
$ vi MyPod.yaml
$ kubectl apply -f MyPod.yaml
Самое важное, что вам нужно знать: если вы измените спецификацию модуля, ваш модуль будет перезапущен для применения изменений. В случае развертывания будет происходить непрерывное обновление. В большинстве случаев это нормально. Если вам нужно сохранить состояние вашего приложения, лучшим способом является хранение ценной информации с использованием томов.
Если вы все еще хотите добавить секреты без перезапуска Pod, вы можете использовать общее хранилище, например NFS. Когда вы изменяете содержимое тома NFS, который уже смонтирован в модуле, изменения сразу же будут видны внутри модуля.
В некоторых случаях вы можете выполнить оболочку внутри модуля и смонтировать том NFS вручную.
Кроме того, вы можете экспортировать содержимое секрета в файл с помощью программы ksd
(или base64 -d) для декодирования закодированных в base64 значений в Secret:
kubectl get secret mysecret -o yaml | ksd > filename.yaml
и скопируйте в модуль, используя следующую команду:
kubectl cp filename.yaml <some-namespace>/<some-pod>:/tmp/secret.yaml