Я пытаюсь настроить кластер azure kubernetes и создать его в проекте port.dockerized .net core webapi, а также опубликовать образ в реестре контейнеров azure. После применения файла манифеста я получаю сообщение о созданной службе, а также внешний IP-адрес. однако, когда я получаю стручки, я все время получаю статус «Ожидание»
NAME READY STATUS RESTARTS AGE
kubdemo1api-6c67bf759f-6slh2 0/1 Pending 0 6h
вот мой файл манифеста yaml, может кто-нибудь подсказать, что здесь не так?
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: kubdemo1api
labels:
name: kubdemo1api
spec:
replicas: 1
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
minReadySeconds: 30
selector:
matchLabels:
app: kubdemo1api
template:
metadata:
labels:
app: kubdemo1api
version: "1.0"
tier: backend
spec:
containers:
- name: kubdemo1api
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
image: my container registry image address
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: azkubdemoapi1
spec:
ports:
-
port: 80
selector:
app: kubdemo1api
type: LoadBalancer
Обновлено: Вывод kubectl описывает pods так:
вот
Normal Scheduled 2m default-scheduler Successfully assigned default/kubdemo1api-697d5655c-64fnj to aks-agentpool-87689508-0
Normal Pulling 37s (x4 over 2m) kubelet, aks-agentpool-87689508-0 pulling image "myacrurl/azkubdemo:v2"
Warning Failed 37s (x4 over 2m) kubelet, aks-agentpool-87689508-0 Failed to pull image "my acr url": [rpc error: code = Unknown desc = Error response from daemon: Get https://myacrurl/v2/azkubdemo/manifests/v2: unauthorized: authentication required, rpc error: code = Unknown desc = Error response from daemon: Get https://myacrurl/v2/azkubdemo/manifests/v2: unauthorized: authentication required]
Warning Failed 37s (x4 over 2m) kubelet, aks-agentpool-87689508-0 Error: ErrImagePull
Normal BackOff 23s (x6 over 2m) kubelet, aks-agentpool-87689508-0 Back-off pulling image "myacrlurl/azkubdemo:v2"
Warning Failed 11s (x7 over 2m) kubelet, aks-agentpool-87689508-0 Error: ImagePullBackOff
добавил в вопрос
Ошибка показывает, что вам необходимо пройти аутентификацию в реестре, чтобы получить образ. Вы можете использовать imagePullSecrets
для аутентификации в реестре. См. пример ACR.
Есть еще вопросы? Или, если совет работает для вас, я бы добавил ответ другим, кто сталкивается с той же проблемой. Пожалуйста, дайте мне знать результат.
аутентификация с использованием imagePullSecrets сработала за меня. Однако перед этим мне пришлось создать секрет в кластере, доступный узлам для использования.
Этот Yaml неверен Можете ли вы предоставить правильный yaml, намерения неверны. Попробуйте ниже YAML
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: kubdemo1api
labels:
name: kubdemo1api
spec:
replicas: 1
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
minReadySeconds: 30
selector:
matchLabels:
app: kubdemo1api
template:
metadata:
labels:
app: kubdemo1api
version: "1.0"
tier: backend
spec:
containers:
- name: kubdemo1api
image: nginx
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: azkubdemoapi1
spec:
ports:
- port: 80
selector:
app: kubdemo1api
type: LoadBalancer
Для ошибки, которую вы предоставляете, это показывает, что вам необходимо пройти аутентификацию, чтобы получить образ из реестра контейнеров Azure.
На самом деле, вам просто нужно разрешение, чтобы вытащить изображение, и роли acrpull
вполне достаточно. Есть два способа добиться этого.
Во-первых, просто предоставьте AKS доступ к реестру контейнеров Azure. С моей стороны проще всего. Просто нужно создать назначение роли для субъекта-службы, который использовал AKS. См. Предоставление AKS доступа к ACR для полных шагов.
Другой — использовать секрет Kubernetes. Он немного сложнее первого. Вам нужно создать новый субъект-службу, отличный от используемого AKS, и предоставить к нему доступ, а затем создать секрет kubernetes с субъектом-службой. См. Доступ с секретом Kubernetes для всех шагов.
можете поделиться выводом
kubectl describe pod kubdemo1api-6c67bf759f-6slh2