Развертывание REST API Golang на AWS EKS завершается сбоем из-за CrashLoopBackOff

Я пытаюсь развернуть простой REST API, написанный на Golang, в AWS EKS.

Я создал кластер EKS на AWS с помощью Terraform и применил к нему диаграмму Helm контроллера балансировки нагрузки AWS.

Все ресурсы в кластере выглядят так:

NAMESPACE     NAME                                                READY   STATUS    RESTARTS   AGE
kube-system   pod/aws-load-balancer-controller-5947f7c854-fgwk2   1/1     Running   0          75m
kube-system   pod/aws-load-balancer-controller-5947f7c854-gkttb   1/1     Running   0          75m
kube-system   pod/aws-node-dfc7r                                  1/1     Running   0          120m
kube-system   pod/aws-node-hpn4z                                  1/1     Running   0          120m
kube-system   pod/aws-node-s6mng                                  1/1     Running   0          120m
kube-system   pod/coredns-66cb55d4f4-5l7vm                        1/1     Running   0          127m
kube-system   pod/coredns-66cb55d4f4-frk6p                        1/1     Running   0          127m
kube-system   pod/kube-proxy-6ndf5                                1/1     Running   0          120m
kube-system   pod/kube-proxy-s95qk                                1/1     Running   0          120m
kube-system   pod/kube-proxy-vdrdd                                1/1     Running   0          120m

NAMESPACE     NAME                                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       service/kubernetes                          ClusterIP   10.100.0.1      <none>        443/TCP         127m
kube-system   service/aws-load-balancer-webhook-service   ClusterIP   10.100.202.90   <none>        443/TCP         75m
kube-system   service/kube-dns                            ClusterIP   10.100.0.10     <none>        53/UDP,53/TCP   127m

NAMESPACE     NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
kube-system   daemonset.apps/aws-node     3         3         3       3            3           <none>          127m
kube-system   daemonset.apps/kube-proxy   3         3         3       3            3           <none>          127m

NAMESPACE     NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/aws-load-balancer-controller   2/2     2            2           75m
kube-system   deployment.apps/coredns                        2/2     2            2           127m

NAMESPACE     NAME                                                      DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/aws-load-balancer-controller-5947f7c854   2         2         2       75m
kube-system   replicaset.apps/coredns-66cb55d4f4                        2         2         2       127m

Я могу запускать приложение локально с помощью Go и Docker. Но выпуск этого на AWS EKS всегда выбрасывает CrashLoopBackOff.

Бег kubectl describe pod PODNAME показывает:

Name:         go-api-55d74b9546-dkk9g
Namespace:    default
Priority:     0
Node:         ip-172-16-1-191.ec2.internal/172.16.1.191
Start Time:   Tue, 15 Mar 2022 07:04:08 -0700
Labels:       app=go-api
              pod-template-hash=55d74b9546
Annotations:  kubernetes.io/psp: eks.privileged
Status:       Running
IP:           172.16.1.195
IPs:
  IP:           172.16.1.195
Controlled By:  ReplicaSet/go-api-55d74b9546
Containers:
  go-api:
    Container ID:   docker://a4bc07b60c85fd308157d967d2d0d688d8eeccfe4c829102eb929ca82fb25595
    Image:          saurabhmish/golang-hello:latest
    Image ID:       docker-pullable://saurabhmish/golang-hello@sha256:f79a495ad17710b569136f611ae3c8191173400e2cbb9cfe416e75e2af6f7874
    Port:           3000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 15 Mar 2022 07:09:50 -0700
      Finished:     Tue, 15 Mar 2022 07:09:50 -0700
    Ready:          False
    Restart Count:  6
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-jt4gp (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-jt4gp:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  7m31s                   default-scheduler  Successfully assigned default/go-api-55d74b9546-dkk9g to ip-172-16-1-191.ec2.internal
  Normal   Pulled     7m17s                   kubelet            Successfully pulled image "saurabhmish/golang-hello:latest" in 12.77458991s
  Normal   Pulled     7m16s                   kubelet            Successfully pulled image "saurabhmish/golang-hello:latest" in 110.127771ms
  Normal   Pulled     7m3s                    kubelet            Successfully pulled image "saurabhmish/golang-hello:latest" in 109.617419ms
  Normal   Created    6m37s (x4 over 7m17s)   kubelet            Created container go-api
  Normal   Started    6m37s (x4 over 7m17s)   kubelet            Started container go-api
  Normal   Pulled     6m37s                   kubelet            Successfully pulled image "saurabhmish/golang-hello:latest" in 218.952336ms
  Normal   Pulling    5m56s (x5 over 7m30s)   kubelet            Pulling image "saurabhmish/golang-hello:latest"
  Normal   Pulled     5m56s                   kubelet            Successfully pulled image "saurabhmish/golang-hello:latest" in 108.105083ms
  Warning  BackOff    2m28s (x24 over 7m15s)  kubelet            Back-off restarting failed container

Бег kubectl logs PODNAME и kubectl logs PODNAME -c go-api шоу standard_init_linux.go:228: exec user process caused: exec format error

Манифесты:

go-deploy.yaml (Это Образ Docker Hub с документацией)

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-api
  labels:
    app: go-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: go-api
  strategy: {}
  template:
    metadata:
      labels:
        app: go-api
    spec:
      containers:
      - name: go-api
        image: saurabhmish/golang-hello:latest
        ports:
          - containerPort: 3000
        resources: {}

go-service.yaml

---
kind: Service
apiVersion: v1
metadata:
  name: go-api
spec:
  selector:
    app: go-api
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000

Как я могу исправить эту ошибку?

Вы создаете образ на M1 Mac (или другом хосте, отличном от Intel)? Я думаю, что EKS в основном основан на x86, и это вызовет сообщение exec format error.

David Maze 15.03.2022 16:23

Да, я собираю его на M1 Mac

Saurabh 15.03.2022 16:53
«Ошибка формата exec» при запуске сборки контейнеров с помощью Apple M1 Chip (системы на базе ARM) предлагает docker buildx build --platform=linux/amd64 вызов, чтобы заставить Docker создать образ x86-64; это тебе помогает?
David Maze 15.03.2022 17:44

@ Дэвид Мейз, не могли бы вы написать это как ответ?

mozello 16.03.2022 09:32

Привет, Саураб, решение, предложенное Дэвидом, решает проблему?

mozello 16.03.2022 15:11

Привет, Мозелло, я скоро попробую ... опубликую подробный ответ, если сделаю

Saurabh 16.03.2022 15:13
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
3
6
107
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

CrashloopBackOff означает, что у вас есть запуск модуля, сбой, запуск снова и снова сбой.

Возможно, ошибка исходит от самого приложения, что оно не может подключиться к базе данных, redis,...

Вы можете найти что-то полезное здесь:

Мои модули kubernetes продолжают падать с ошибкой «CrashLoopBackOff», но я не могу найти журнал.

Ответ принят как подходящий

Опубликовать это как вики сообщества для лучшей видимости. Не стесняйтесь расширять его.


Спасибо @David Maze, который указал на решение. Есть статья «Создание образов Docker, совместимых с Intel64, из Mac M1 (ARM)» (от Беппе Катанезе) здесь.
В этой статье хорошо описана основная проблема.

Вы разрабатываете/строите на архитектуре ARM (Mac M1), но развертываете образ докера в кластере Kubernetes на основе архитектуры x86-64.

Решение:

Вариант А: используйте buildx

Buildx — это плагин Docker, который позволяет, помимо прочего, создавать образы для различных целевых платформ.

$ docker buildx build --platform linux/amd64 -t myapp .

Вариант Б: установить DOCKER_DEFAULT_PLATFORM

Переменная среды DOCKER_DEFAULT_PLATFORM позволяет установить платформу по умолчанию для команд, которые принимают флаг --platform.

export DOCKER_DEFAULT_PLATFORM=linux/amd64

Другие вопросы по теме