ฝัก kubernetes ของฉันขัดข้องด้วย "CrashLoopBackOff" แต่ฉันไม่พบบันทึกใด ๆ

นี่คือสิ่งที่ฉันได้รับ:

[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

ด้านล่างนี้เป็นผลลัพธ์จาก "อธิบายพ็อด " kubectl อธิบายพ็อด

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)"

ฉันมีสองพ็อด: nfs-web-07rxz, nfs-web-fdr9h แต่ถ้าฉันทำ "บันทึก kubectl nfs-web-07rxz" หรือด้วยตัวเลือก "-p" ฉันไม่เห็นบันทึกในพ็อดทั้งสอง

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

นี่คือไฟล์ yaml replicationController ของฉัน: ไฟล์ replicationController yaml

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 ของฉันสร้างขึ้นจากไฟล์นักเทียบท่าธรรมดานี้:

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

ฉันกำลังเรียกใช้คลัสเตอร์ kubernetes ของฉันบน CentOs-1611 เวอร์ชัน kube:

[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"}

หากฉันเรียกใช้อิมเมจนักเทียบท่าโดย "นักเทียบท่าวิ่ง" ฉันสามารถเรียกใช้ภาพได้โดยไม่มีปัญหาใด ๆ เพียงผ่านทาง kubernetes เท่านั้นที่ฉันได้รับความผิดพลาด

ใครสามารถช่วยฉันฉันจะแก้ปัญหาโดยไม่เห็นบันทึกใด ๆ

ตามที่ @Sukumar แสดงความคิดเห็นคุณต้องให้ Dockerfile ของคุณมีคำสั่งเพื่อเรียกใช้หรือให้ ReplicationController ระบุคำสั่ง

พ็อดหยุดทำงานเนื่องจากเริ่มต้นแล้วออกทันที Kubernetes จึงรีสตาร์ทและวงจรจะดำเนินต่อ

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

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

ฉันจำเป็นต้องให้พ็อดทำงานต่อไปสำหรับการเรียกใช้kubectl exec ในภายหลังและตามที่ความคิดเห็นด้านบนชี้ให้เห็นว่าพ็อดของฉันถูกคลัสเตอร์ k8s ของฉันตายเพราะมันทำงานทั้งหมดเสร็จแล้ว ฉันจัดการเพื่อให้พ็อดของฉันทำงานได้โดยเพียงแค่เตะพ็อดด้วยคำสั่งที่จะไม่หยุดโดยอัตโนมัติดังใน:

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

หากคุณมีแอปพลิเคชันที่บูตสแตรปช้าลงอาจเกี่ยวข้องกับค่าเริ่มต้นของโพรบความพร้อม / ความเป็นอยู่ ฉันแก้ไขปัญหาโดยเพิ่มค่าinitialDelaySecondsเป็น 120 เนื่องจากSpringBootแอปพลิเคชันของฉันเกี่ยวข้องกับการเริ่มต้นจำนวนมาก เอกสารประกอบไม่ได้กล่าวถึงค่าเริ่มต้น 0 ( 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

คำอธิบายที่ดีมากเกี่ยวกับค่าเหล่านั้นจะได้รับจากสิ่งที่เป็นค่าเริ่มต้นของ initialDelaySeconds

อัลกอริทึมการตรวจสุขภาพหรือความพร้อมทำงานเช่น:

1. รอ initialDelaySeconds
2. ตรวจสอบและรอtimeoutSecondsการหมดเวลาหากจำนวนความสำเร็จต่อเนื่องมากกว่าsuccessThresholdความสำเร็จที่ส่งคืน
3. หากจำนวนความล้มเหลวต่อเนื่องมากกว่าfailureThresholdความล้มเหลวในการส่งคืนมิฉะนั้นให้รอperiodSecondsและเริ่มการตรวจสอบใหม่

ในกรณีของฉันตอนนี้แอปพลิเคชันของฉันสามารถบูตสแตรปได้อย่างชัดเจนดังนั้นฉันจึงรู้ว่าฉันจะไม่ได้รับ crashloopbackoff เป็นระยะเพราะบางครั้งอาจอยู่ในขีด จำกัด ของอัตราเหล่านั้น

จากหน้านี้คอนเทนเนอร์จะตายหลังจากรันทุกอย่างถูกต้อง แต่หยุดทำงานเนื่องจากคำสั่งทั้งหมดสิ้นสุดลง ไม่ว่าคุณจะทำให้บริการของคุณทำงานบนพื้นหน้าหรือคุณสร้างสคริปต์ Keep alive เมื่อทำเช่นนั้น Kubernetes จะแสดงว่าแอปพลิเคชันของคุณกำลังทำงานอยู่ เราต้องสังเกตว่าในDockerสภาพแวดล้อมไม่พบปัญหานี้ มีเพียง Kubernetes เท่านั้นที่ต้องการแอปที่ทำงานอยู่

อัปเดต (ตัวอย่าง):

วิธีหลีกเลี่ยงCrashLoopBackOffเมื่อเปิดใช้งานคอนเทนเนอร์Netshoot :

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

พ็อดของฉันยังคงขัดข้องและฉันไม่สามารถหาสาเหตุได้ โชคดีที่มีพื้นที่ที่ Kubernetes บันทึกทุกเหตุการณ์ที่เกิดขึ้นก่อนฝักของฉันล้มเหลว
(# กิจกรรมในรายการเรียงตามการประทับเวลา)

หากต้องการดูเหตุการณ์เหล่านี้ให้รันคำสั่ง:

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

อย่าลืมเพิ่ม--namespace mynamespaceอาร์กิวเมนต์ให้กับคำสั่งหากจำเป็น

เหตุการณ์ที่แสดงในผลลัพธ์ของคำสั่งแสดงให้เห็นว่าเหตุใดพ็อดของฉันจึงหยุดทำงาน

ในไฟล์ yaml ของคุณให้เพิ่มบรรทัดคำสั่งและ args:

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

เหมาะสำหรับฉัน

ฉันสังเกตเห็นปัญหาเดียวกันและเพิ่มคำสั่งและ args block ในไฟล์ yaml ฉันกำลังคัดลอกตัวอย่างไฟล์ yaml ของฉันเพื่อใช้อ้างอิง

 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

ในกรณีของฉันปัญหาคือสิ่งที่ Steve S. กล่าวถึง:

พ็อดหยุดทำงานเนื่องจากเริ่มต้นแล้วออกทันที Kubernetes จึงรีสตาร์ทและวงจรจะดำเนินต่อ

กล่าวคือฉันมีแอปพลิเคชัน Java ที่mainมีข้อยกเว้น (และมีบางอย่างลบล้างตัวจัดการข้อยกเว้นที่ไม่ได้ตรวจพบโดยปริยายเพื่อให้ไม่มีการบันทึก) วิธีแก้ปัญหาคือใส่เนื้อหาmainลงในtry { ... } catchและพิมพ์ข้อยกเว้น ดังนั้นฉันจึงสามารถค้นหาสิ่งที่ผิดพลาดและแก้ไขได้

(สาเหตุอีกประการหนึ่งอาจเกิดจากการเรียกใช้แอปSystem.exitคุณสามารถใช้แบบกำหนดเองที่SecurityManagerมีการลบล้างcheckExitเพื่อป้องกัน (หรือบันทึกผู้โทร) ออกดูhttps://stackoverflow.com/a/5401319/204205 )

kubeclt logs <pod_id>ขณะที่การแก้ปัญหาเดียวกันที่ผมพบว่าไม่มีการบันทึกเมื่อมีการใช้ ดังนั้นฉันจึง ssh: ed ในอินสแตนซ์โหนดเพื่อพยายามเรียกใช้คอนเทนเนอร์โดยใช้นักเทียบท่าธรรมดา ทำให้ฉันประหลาดใจนี้ล้มเหลวเช่นกัน

เมื่อเข้าสู่ภาชนะด้วย:

docker exec -it faulty:latest /bin/sh

และฉันก็พบว่ามันไม่ใช่เวอร์ชันล่าสุด

อิมเมจนักเทียบท่ารุ่นที่ผิดพลาดมีอยู่แล้วในอินสแตนซ์

เมื่อฉันลบข้อผิดพลาด: อินสแตนซ์ล่าสุดด้วย:

docker rmi faulty:latest

ทุกอย่างเริ่มทำงาน

ฉันแก้ปัญหานี้ได้ฉันเพิ่มทรัพยากรหน่วยความจำ

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

ฉันมีปัญหาเดียวกันและตอนนี้ฉันก็แก้ไขได้ในที่สุด ฉันไม่ได้ใช้ไฟล์ Docker-compose ฉันเพิ่งเพิ่มบรรทัดนี้ในไฟล์ Docker ของฉันและมันใช้งานได้

ENV CI=true

อ้างอิง: https://github.com/GoogleContainerTools/skaffold/issues/3882

ลองเรียกใช้พ็อดใหม่และเรียกใช้

 kubectl get pods --watch

เพื่อดูสถานะของพ็อดเมื่อมันดำเนินไป

ในกรณีของฉันฉันจะเห็นผลลัพธ์สุดท้ายคือ "CrashLoopBackOff" เท่านั้น แต่คอนเทนเนอร์นักเทียบท่าทำงานได้ดีในพื้นที่ ดังนั้นฉันจึงดูพ็อดโดยใช้คำสั่งด้านบนและฉันเห็นว่าคอนเทนเนอร์กำลังดำเนินการอยู่ในสถานะ OOMKilledในช่วงสั้น ๆซึ่งหมายความว่าฉันต้องการหน่วยความจำมากขึ้น

ฉันแก้ไขปัญหานี้โดยการลบช่องว่างระหว่างเครื่องหมายคำพูดและค่าคำสั่งภายในอาร์เรย์สิ่งนี้เกิดขึ้นเนื่องจากคอนเทนเนอร์ออกหลังจากเริ่มต้นและไม่มีคำสั่งที่เรียกใช้งานได้ซึ่งจะเรียกใช้ภายในคอนเทนเนอร์

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

ฉันมีปัญหาที่คล้ายกัน แต่ได้รับการแก้ไขเมื่อฉันแก้ไขzookeeper.yamlไฟล์ของฉันซึ่งมีชื่อบริการไม่ตรงกันกับชื่อคอนเทนเนอร์ของการปรับใช้ไฟล์ ได้รับการแก้ไขโดยทำให้เหมือนกัน

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