#kubernetes #azure-aks
#kubernetes #azure-aks
Вопрос:
Я использую AKS (v1.20.9). Я пытаюсь развернуть StatefulSet, который использует общий файловый ресурс Azure в качестве PV в моем кластере.
Мой модуль застрял в ContainerCreating
состоянии, и я получаю следующую ошибку :
│ Warning FailedMount 8m57s (x2 over 8m58s) kubelet MountVolume.SetUp failed for volume "buy-vol" : Couldn't get secret ns1/app-buy-secret │
│ Warning FailedMount 6m55s kubelet Unable to attach or mount volumes: unmounted volumes=[buy-vol], unattached volumes=[buy-vol│
Мои PV и PVC были созданы успешно :
kubectl get pv/app-buy-azure-file -n ns1
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
app-buy-azure-file 200Mi RWX Retain Bound ns1/app-buy-azure-file 14m
Мои секреты создаются через SecretProviderClass
(поскольку секреты сохраняются в Azure Key Vault) и доступны через kubectl :
kubectl get secret/app-buy-secret -n ns1
NAME TYPE DATA AGE
app-buy-secret Opaque 5 16m
Под секретом я получил ключи azurestorageaccountkey
и azurestorageaccountname
:
kubectl describe secret/app-buy-secret -n ns1
Name: app-buy-secret
Namespace: ns1
Labels: secrets-store.csi.k8s.io/managed=true
Annotations: <none>
Type: Opaque
Data
====
azurestorageaccountname: 23 bytes
app-secret: 36 bytes
tenant-secret: 37 bytes
azurestorageaccountkey: 88 bytes
В чем может быть проблема?
StatefulSet yaml :
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: {{ .Chart.Name }}-statefulset
labels:
{{- include "..labels" . | nindent 4 }}
spec:
serviceName: {{ .Chart.Name }}-service
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "..selectorLabels" . | nindent 6 }}
template:
metadata:
{{- with .Values.podAnnotations }}
annotations:
{{- toYaml . | nindent 8 }}
{{- end }}
labels:
{{- include "..selectorLabels" . | nindent 8 }}
aadpodidbinding: ״app-buy-binding-selector"
spec:
serviceAccountName: {{ include "..serviceAccountName" . }}
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
ports:
- name: http
containerPort: 8080
protocol: TCP
resources:
{{- toYaml .Values.resources | nindent 12 }}
volumeMounts:
- mountPath: /mnt/secrets-store
name: secrets-vol
readOnly: true
- mountPath: /app/store/
name: buy-vol
volumes:
- name: secrets-vol
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: {{ .Chart.Name }}-secret-provider-class
- name: buy-vol
persistentVolumeClaim:
claimName: {{ .Chart.Name }}-azure-file
Роль и привязка роли к ServiceAccount :
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: {{ .Release.Namespace }}
name: {{ .Release.Namespace }}-ns-reader
rules:
- apiGroups: [""]
resources: ["configmaps", "pods", "services", "endpoints", "secrets"]
verbs: ["get", "list", "watch"]
---
{{- if .Values.serviceAccount.create -}}
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: {{ include "..serviceAccountName" . }}-binding
subjects:
- kind: ServiceAccount
namespace: {{ .Release.Namespace }}
name: {{ include "..serviceAccountName" . }}
apiGroup: ""
roleRef:
kind: Role
name: {{ .Release.Namespace }}-ns-reader
apiGroup: ""
{{- end -}}
При необходимости я могу добавить также yaml для pv / pvc…
Комментарии:
1. Я думаю, что serviceacoount для модулей не создан, пожалуйста, проверьте, какая учетная запись службы используется для pod, и проверьте, существует ли эта учетная запись службы или учетная запись службы не имеет авторизации для доступа к секрету (привязка ролей / привязка кластеров)
2. Как вы думаете, почему проблема в serviceaccount здесь?
3. ошибка:
Couldn't get secret ns1/app-buy-secret
из выходных данных в системе присутствует секрет, поэтому другой очевидной причиной может быть то, что учетная запись службы не имеет разрешения на ее чтение.4. Учетная запись службы существует и должна иметь доступ к секретам (я могу получить доступ к другим ключам в секрете без pvc / pv. Я добавляю yamls привязки роли учетной записи службы
5. роль и привязка ролей, похоже, в порядке, похоже ли это на упоминание о проблеме в github.com/kubernetes/kubernetes/issues/99061