Kubernetes kapsüllerim "CrashLoopBackOff" ile çökmeye devam ediyor ancak herhangi bir günlük bulamıyorum

İşte bunu almaya devam ediyorum:

[root@centos-master ~]# kubectl get pods
NAME               READY     STATUS             RESTARTS   AGE
nfs-server-h6nw8   1/1       Running            0          1h
nfs-web-07rxz      0/1       CrashLoopBackOff   8          16m
nfs-web-fdr9h      0/1       CrashLoopBackOff   8          16m

Aşağıda " kapsülleri tanımlayın " kubectl açıklama kapsüllerindeki çıktı bulunmaktadır

Events:
  FirstSeen LastSeen    Count   From                SubobjectPath       Type        Reason      Message
  --------- --------    -----   ----                -------------       --------    ------      -------
  16m       16m     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned nfs-web-fdr9h to centos-minion-2
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id d56f34ae4e8f
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id d56f34ae4e8f
  16m       16m     2   {kubelet centos-minion-2}               Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "web" with CrashLoopBackOff: "Back-off 10s restarting failed container=web pod=nfs-web-fdr9h_default(461c937d-d870-11e6-98de-005056040cc2)"

İki bölmem var: nfs-web-07rxz, nfs-web-fdr9h, ancak "kubectl logs nfs-web-07rxz" yaparsam veya "-p" seçeneğiyle her iki bölmede de herhangi bir günlük görmüyorum.

[root@centos-master ~]# kubectl logs nfs-web-07rxz -p
[root@centos-master ~]# kubectl logs nfs-web-07rxz

Bu benim replicationController yaml dosyam: replicationController yaml dosyası

apiVersion: v1 kind: ReplicationController metadata:   name: nfs-web spec:   replicas: 2   selector:
    role: web-frontend   template:
    metadata:
      labels:
        role: web-frontend
    spec:
      containers:
      - name: web
        image: eso-cmbu-docker.artifactory.eng.vmware.com/demo-container:demo-version3.0
        ports:
          - name: web
            containerPort: 80
        securityContext:
          privileged: true

Docker imajım şu basit docker dosyasından yapıldı:

FROM ubuntu
RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get install -y nfs-common

Kubernetes kümemi CentOs-1611, kube sürümünde çalıştırıyorum:

[root@centos-master ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Docker imajını "docker run" ile çalıştırırsam, imajı herhangi bir sorun olmadan çalıştırabildim, sadece kubernetes üzerinden çöktü.

Birisi bana yardım edebilir mi, herhangi bir günlük görmeden nasıl hata ayıklayabilirim?

@Sukumar'ın da belirttiği gibi, Dockerfile'ınızda çalıştırmak için bir Komuta sahip olmanız veya ReplicationController'ınızın bir komut belirtmesini sağlamanız gerekir .

Bölme çöküyor çünkü başlıyor ve hemen çıkıyor, böylece Kubernetes yeniden başlıyor ve döngü devam ediyor.

kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name> 

Sonraki kubectl exec çağrıları için bir bölmeyi çalıştırmaya ihtiyacım vardı ve yukarıdaki yorumların işaret ettiği gibi, podum k8s kümem tarafından öldürülüyordu çünkü tüm görevlerini çalıştırmayı tamamlamıştı. Kapsülü aşağıdaki gibi otomatik olarak durmayacak bir komutla basitçe tekmeleyerek çalışır durumda tutmayı başardım:

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null

Daha yavaş önyükleme yapan bir uygulamanız varsa, bu, hazır olma / canlılık araştırmalarının başlangıç ​​değerleriyle ilgili olabilir. Uygulamam çok fazla başlatma ile initialDelaySecondsuğraşırken değerini 120'lere çıkararak sorunumu çözdüm SpringBoot. Dokümantasyon yok değil varsayılan 0 bahsetmek ( https://kubernetes.io/docs/api-reference/v1.9/#probe-v1-core )

service:
  livenessProbe:
    httpGet:
      path: /health/local
      scheme: HTTP
      port: 8888
    initialDelaySeconds: 120
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10
  readinessProbe:
    httpGet:
      path: /admin/health
      scheme: HTTP
      port: 8642
    initialDelaySeconds: 150
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10

Bu değerler hakkında çok iyi bir açıklama , initialDelaySeconds'un varsayılan değeri nedir bölümünde verilmiştir .

Sağlık veya hazırlık kontrolü algoritması şu şekilde çalışır:

1. bekle initialDelaySeconds
2. Kontrol gerçekleştirin ve timeoutSecondsdevam eden başarıların sayısı successThresholdgeri dönüş başarısından fazlaysa zaman aşımını bekleyin
3. devam eden arızaların sayısı failureThresholddönüş arızasından fazlaysa, aksi takdirde bekleyin periodSecondsve yeni bir kontrol başlatın

Benim durumumda, uygulamam artık çok net bir şekilde önyükleme yapabilir, böylece periyodik crashloopbackoff almayacağımı biliyorum çünkü bazen bu oranların sınırında olabilir.

Gönderen Bu sayfa tüm komutlar bittiği için, konteyner her şeyi doğru çalıştırdıktan sonra ölür ama çöker. Ya hizmetlerinizi ön planda çalıştırırsınız ya da canlı tutma betiği yaratırsınız. Bunu yaparak, Kubernetes uygulamanızın çalıştığını gösterecektir. DockerÇevrede bu problemle karşılaşılmadığına dikkat etmeliyiz . Çalışan bir uygulama isteyen yalnızca Kubernetes'tir.

Güncelleme (bir örnek):

Bir Netshoot kapsayıcısı başlatırken CrashLoopBackOff'tan nasıl kaçınacağınız aşağıda açıklanmıştır :

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity

Bölmem çökmeye devam etti ve sebebini bulamadım. Neyse ki, kubernetes'in podum çökmeden önce meydana gelen tüm olayları kaydettiği bir alan var .
(# Zaman damgasına göre sıralanmış Olaylar Listesi)

Bu olayları görmek için şu komutu çalıştırın:

kubectl get events --sort-by=.metadata.creationTimestamp

--namespace mynamespacegerekirse komuta bir argüman eklediğinizden emin olun

Komutun çıktısında gösterilen olaylar, podumun neden çökmeye devam ettiğini gösterdi.

Yaml dosyanıza komut ve args satırları ekleyin:

...
containers:
      - name: api
        image: localhost:5000/image-name 
        command: [ "sleep" ]
        args: [ "infinity" ]
...

Benim için çalışıyor.

Aynı sorunu gözlemledim ve yaml dosyasına komut ve args bloğunu ekledim. Referans için yaml dosyamın örneğini kopyalıyorum

 apiVersion: v1
    kind: Pod
    metadata:
      labels:
        run: ubuntu
      name: ubuntu
      namespace: default
    spec:
      containers:
      - image: gcr.io/ow/hellokubernetes/ubuntu
        imagePullPolicy: Never
        name: ubuntu
        resources:
          requests:
            cpu: 100m
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
      dnsPolicy: ClusterFirst
      enableServiceLinks: true

Benim durumumda sorun Steve S.'in bahsettiği şeydi:

Bölme çöküyor çünkü başlıyor ve hemen çıkıyor, böylece Kubernetes yeniden başlıyor ve döngü devam ediyor.

Yani mainbir istisna atan bir Java uygulamam vardı (ve bir şey varsayılan yakalanmamış istisna işleyicisini geçersiz kılarak hiçbir şey günlüğe kaydedilmedi). Solüsyon gövdesini koymak oldu mainiçine try { ... } catchve istisna çıktısını. Böylece neyin yanlış olduğunu bulup düzeltebildim.

(Başka bir neden, uygulamada arama yapan bir şey System.exitolabilir ; çıkışı önlemek (veya arayanın kaydını tutmak) için SecurityManagergeçersiz kılınmış bir özel kullanabilirsiniz checkExit; bkz. Https://stackoverflow.com/a/5401319/204205 .)

Aynı sorunu giderirken kullanırken hiçbir günlük bulamadım kubeclt logs <pod_id>. Bu nedenle, kapsayıcıyı düz docker kullanarak çalıştırmayı denemek için düğüm örneğine ssh: ed. Şaşırtıcı bir şekilde bu da başarısız oldu.

Konteynere şu şekilde girerken:

docker exec -it faulty:latest /bin/sh

ve etrafta dolanırken bunun en son sürüm olmadığını anladım.

Docker görüntüsünün hatalı bir sürümü örnekte zaten mevcuttu.

Hatalı son örneği kaldırdığımda:

docker rmi faulty:latest

her şey çalışmaya başladı.

Bu sorunu çözdüm bellek kaynağını artırdım

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi 

Aynı sorunu yaşadım ve şimdi nihayet çözdüm. Docker-compose dosyasını kullanmıyorum. Bu satırı Docker dosyama ekledim ve işe yaradı.

ENV CI=true

Referans: https://github.com/GoogleContainerTools/skaffold/issues/3882

Bölmeyi yeniden çalıştırmayı ve koşmayı deneyin

 kubectl get pods --watch

bölmenin durumunu ilerledikçe izlemek için.

Benim durumumda, yalnızca 'CrashLoopBackOff' sonucunu görürdüm, ancak docker container yerel olarak iyi çalıştı. Bu yüzden yukarıdaki komutu kullanarak bölmeleri izledim ve kabın kısaca OOMKilled durumuna geçtiğini gördüm , bu da benim için daha fazla bellek gerektirdiği anlamına geliyordu.

Bu sorunu, dizinin içindeki tırnaklar ve komut değeri arasındaki boşluğu kaldırarak çözdüm, bunun nedeni konteynerin başlatıldıktan sonra çıkması ve konteynerin içinde çalıştırılacak çalıştırılabilir komut olmamasıdır.

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Benzer bir sorun yaşadım, ancak zookeeper.yamlhizmet adı dosya dağıtımının kapsayıcı adlarıyla uyumsuz olan dosyamı düzelttiğimde çözüldüm. Aynı yapılarak çözüldü.

apiVersion: v1
kind: Service
metadata:
  name: zk1
  namespace: nbd-mlbpoc-lab
  labels:
    app: zk-1
spec:
  ports:
  - name: client
    port: 2181
    protocol: TCP
  - name: follower
    port: 2888
    protocol: TCP
  - name: leader
    port: 3888
    protocol: TCP
  selector:
    app: zk-1
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: zk-deployment
  namespace: nbd-mlbpoc-lab
spec:
  template:
    metadata:
      labels:
        app: zk-1
    spec:
      containers:
      - name: zk1
        image: digitalwonderland/zookeeper
        ports:
        - containerPort: 2181
        env:
        - name: ZOOKEEPER_ID
          value: "1"
        - name: ZOOKEEPER_SERVER_1
          value: zk1