Các nhóm kubernetes của tôi liên tục gặp sự cố với “CrashLoopBackOff” nhưng tôi không thể tìm thấy bất kỳ nhật ký nào

Đây là những gì tôi tiếp tục nhận được:

[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

Dưới đây là đầu ra từ "mô tả nhóm" kubectl mô tả nhóm

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

Tôi có hai nhóm: nfs-web-07rxz, nfs-web-fdr9h, nhưng nếu tôi làm "kubectl nhật ký nfs-web-07rxz" hoặc với tùy chọn "-p", tôi không thấy bất kỳ nhật ký nào trong cả hai nhóm.

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

Đây là tệp replicationController yaml của tôi: tệp 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

Hình ảnh Docker của tôi được tạo từ tệp docker đơn giản này:

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

Tôi đang chạy cụm kubernetes của mình trên CentOs-1611, phiên bản 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"}

Nếu tôi chạy hình ảnh docker bằng "docker run", tôi có thể chạy hình ảnh mà không gặp vấn đề gì, chỉ thông qua kubernetes, tôi đã gặp sự cố.

Ai đó có thể giúp tôi, làm thế nào tôi có thể gỡ lỗi mà không thấy bất kỳ nhật ký nào?

Như @Sukumar đã nhận xét, bạn cần có Dockerfile của mình có Lệnh để chạy hoặc để ReplicationController của bạn chỉ định một lệnh.

Nhóm bị lỗi vì nó khởi động sau đó thoát ra ngay lập tức, do đó Kubernetes khởi động lại và chu kỳ tiếp tục.

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

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

Tôi có nhu cầu giữ một nhóm chạy cho các cuộc gọi thực thi kubectl tiếp theo và như các nhận xét ở trên chỉ ra rằng nhóm của tôi đã bị giết bởi cụm k8s của tôi vì nó đã hoàn thành chạy tất cả các nhiệm vụ của nó. Tôi đã quản lý để giữ cho nhóm của mình hoạt động bằng cách chỉ cần đá vào nhóm bằng một lệnh sẽ không tự động dừng lại như trong:

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

Nếu bạn có một ứng dụng khởi động chậm hơn, nó có thể liên quan đến các giá trị ban đầu của các đầu dò độ sẵn sàng / độ sống. Tôi đã giải quyết vấn đề của mình bằng cách tăng giá trị initialDelaySecondslên 120 giây vì SpringBootứng dụng của tôi xử lý nhiều lần khởi tạo. Tài liệu không đề cập đến 0 mặc định ( 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

Giải thích rất tốt về những giá trị đó được đưa ra bởi Giá trị mặc định của InitialDelaySeconds là gì .

Thuật toán kiểm tra sức khỏe hoặc mức độ sẵn sàng hoạt động như sau:

1. chờ initialDelaySeconds
2. thực hiện kiểm tra và chờ timeoutSecondshết thời gian chờ nếu số lần tiếp tục thành công nhiều hơn số lần successThresholdtrả lại thành công
3. nếu số lần thất bại tiếp tục nhiều hơn failureThresholdlỗi quay lại, nếu không, hãy đợi periodSecondsvà bắt đầu kiểm tra mới

Trong trường hợp của tôi, ứng dụng của tôi hiện có thể khởi động theo một cách rất rõ ràng, vì vậy tôi biết rằng tôi sẽ không nhận được lỗi crashloopback định kỳ vì đôi khi nó sẽ nằm trong giới hạn của những tỷ lệ đó.

Từ trang này , vùng chứa sẽ chết sau khi chạy mọi thứ chính xác nhưng bị treo vì tất cả các lệnh đã kết thúc. Hoặc bạn làm cho các dịch vụ của mình chạy trên nền trước hoặc bạn tạo một tập lệnh duy trì hoạt động. Bằng cách đó, Kubernetes sẽ hiển thị rằng ứng dụng của bạn đang chạy. Chúng ta phải lưu ý rằng trong Dockermôi trường, vấn đề này không gặp phải. Chỉ Kubernetes muốn một ứng dụng đang chạy.

Cập nhật (một ví dụ):

Đây là cách tránh CrashLoopBackOff khi khởi chạy vùng chứa Netshoot :

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

Vỏ của tôi liên tục gặp sự cố và tôi không thể tìm ra nguyên nhân. May mắn thay, có một không gian nơi kubernetes lưu tất cả các sự kiện xảy ra trước khi nhóm của tôi gặp sự cố .
(# Sự kiện trong danh sách được sắp xếp theo dấu thời gian)

Để xem các sự kiện này, hãy chạy lệnh:

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

đảm bảo thêm --namespace mynamespaceđối số vào lệnh nếu cần

Các sự kiện được hiển thị trong đầu ra của lệnh cho tôi biết lý do tại sao nhóm của tôi liên tục gặp sự cố.

Trong tệp yaml của bạn, thêm các dòng lệnh và args:

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

Làm việc cho tôi.

Tôi đã quan sát thấy vấn đề tương tự và đã thêm lệnh và khối args trong tệp yaml. Tôi đang sao chép mẫu tệp yaml của mình để tham khảo

 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

Trong trường hợp của tôi, vấn đề là những gì Steve S. đã đề cập:

Nhóm bị lỗi vì nó khởi động sau đó thoát ra ngay lập tức, do đó Kubernetes khởi động lại và chu kỳ tiếp tục.

Cụ thể là tôi có một ứng dụng Java mainđã ném một ngoại lệ (và một cái gì đó đã ghi đè lên trình xử lý ngoại lệ chưa được ghi mặc định để không có gì được ghi lại). Giải pháp là đưa phần thân của mainvào try { ... } catchvà in ra ngoại lệ. Vì vậy, tôi có thể tìm ra những gì sai và sửa chữa nó.

(Một nguyên nhân khác có thể là thứ gì đó trong ứng dụng đang gọi System.exit; bạn có thể sử dụng tùy chỉnh SecurityManagercó ghi đè checkExitđể ngăn (hoặc ghi nhật ký người gọi) thoát; xem https://stackoverflow.com/a/5401319/204205 .)

Trong khi khắc phục sự cố tương tự, tôi không tìm thấy nhật ký nào khi sử dụng kubeclt logs <pod_id>. Do đó, tôi ssh: ed vào phiên bản nút để cố gắng chạy vùng chứa bằng cách sử dụng docker đơn giản. Tôi ngạc nhiên là điều này cũng không thành công.

Khi nhập vùng chứa với:

docker exec -it faulty:latest /bin/sh

và xem xét xung quanh tôi thấy rằng nó không phải là phiên bản mới nhất.

Phiên bản lỗi của hình ảnh docker đã có sẵn trên phiên bản này.

Khi tôi xóa phiên bản bị lỗi: mới nhất với:

docker rmi faulty:latest

mọi thứ bắt đầu hoạt động.

Tôi đã giải quyết vấn đề này, tôi đã tăng tài nguyên bộ nhớ

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

Tôi đã gặp vấn đề tương tự và bây giờ tôi cuối cùng đã giải quyết nó. Tôi không sử dụng tệp docker-compile. Tôi vừa thêm dòng này vào tệp Docker của mình và nó đã hoạt động.

ENV CI=true

Tham khảo: https://github.com/GoogleContainerTools/skaffold/issues/3882

Thử chạy lại nhóm và chạy

 kubectl get pods --watch

để xem trạng thái của nhóm khi nó tiến triển.

Trong trường hợp của tôi, tôi sẽ chỉ thấy kết quả cuối cùng, 'CrashLoopBackOff,' nhưng vùng chứa docker chạy tốt cục bộ. Vì vậy, tôi đã xem các nhóm bằng cách sử dụng lệnh trên và tôi thấy vùng chứa tiến triển nhanh chóng sang trạng thái OOMKilled , điều đó có nghĩa là với tôi rằng nó cần nhiều bộ nhớ hơn.

tôi đã giải quyết vấn đề này bằng cách loại bỏ khoảng cách giữa các dấu ngoặc kép và giá trị lệnh bên trong của mảng, điều này xảy ra vì vùng chứa đã thoát sau khi bắt đầu và không có lệnh thực thi nào được chạy bên trong vùng chứa.

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

Tôi gặp sự cố tương tự nhưng đã được giải quyết khi tôi sửa zookeeper.yamltệp của mình có tên dịch vụ không khớp với tên vùng chứa của triển khai tệp. Nó đã được giải quyết bằng cách làm cho chúng giống nhau.

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