Kubernetes bị mắc kẹt trên ContainerCreating

100

Một nhóm trong cụm Kubernetes của tôi bị kẹt trên "ContainerCreating" sau khi chạy tạo. Làm cách nào để xem nhật ký cho thao tác này để chẩn đoán tại sao nó bị kẹt? kubectl logsdường như không hoạt động vì container cần ở trạng thái không chờ xử lý.

kubernetes

— bốn43
nguồn

kubernetes.io/docs/con accept / workloads / pods / pdf-lifecycle / Lỗi là tài liệu về các giai đoạn có thể. Thật không may, nó không bao gồm ContainerCreating...

— Xiong Chiamiov

Câu trả lời:

126

kubectl describe podssẽ liệt kê tất cả các sự kiện liên quan đến nhóm, bao gồm kéo hình ảnh, bắt đầu các thùng chứa. Nó có thể giúp đỡ.

— Saletanth Pothanis
nguồn

Điều gì xảy ra nếu container bị kẹt tại ContainerCreating mà không có sự kiện nào? đối với tôi các sự kiện được hiển thị là "Không có sự kiện."

— Bob

Một số sự kiện dường như mất một thời gian để hiển thị. Ví dụ, thời gian chờ để gắn đĩa cho tôi mất khoảng 2 phút trước khi nó xuất hiện dưới dạng sự kiện.

— jwadsack

Nó xảy ra khi bạn đang sử dụng các bí mật và chúng không được tìm thấy (như lỗi đánh máy trong yaml hoặc bạn quên tạo nó trước đó). Đối với hầu hết các lỗi khác có thể xảy ra, nó bị CrashLoopback hoặc các trạng thái Lỗi nhưng với các bí mật, nó sẽ bị kẹt trong ContainerCreating, nếu bạn mô tả nhóm thì cuối cùng bạn sẽ thấy một thông báo nói rằng bí mật không được tìm thấy, nhưng nó hầu như không nói không có gì về vấn đề

— danius

Vâng thường thì bạn không có bất kỳ sự kiện nào trước khi anh ấy bắt đầu làm gì đó.

— erikbwork

Đã xảy ra với tôi sáng nay và đó là một lỗi đánh máy trong một hostPath cho một tập. Bàn phím dính Yay.

— Joe Block

Trong trường hợp của tôi, truy cập internet của docker đã bị chặn. Nó đã được giải quyết bằng proxy ( sử dụng bình luận của sandylss ):

minikube stop
minikube delete
export http_proxy=http://user:pass@ip:port
export https_proxy=http://user:pass@ip:port
export no_proxy=192.168.99.0/24

minikube start --logtostderr --v=0 --bootstrapper=localkube --vm-driver hyperv 
  --hyperv-virtual-switch "Primary Virtual Switch" --docker-env HTTP_PROXY=$http_proxy \
  --docker-env HTTPS_PROXY=$https_proxy --docker-env NO_PROXY=$no_proxy

export no_proxy=$no_proxy,$(minikube ip)
export NO_PROXY=$no_proxy,$(minikube ip)

Sau đó, để kiểm tra xem docker có truy cập internet hay không, hãy chạy:

$ docker pull tutum/hello-world

trong cụm (kết nối với cụm bằng cách sử dụng minikube ssh); dừng quá trình nếu nó bắt đầu tải xuống.

Vấn đề thứ hai của tôi là kết nối internet chậm. Vì các hình ảnh docker được yêu cầu là theo thứ tự 100MB, cả hai container docker và pod Kubernetes vẫn ở trong \pausevà ContainerCreatingtrạng thái trong 30 phút.

Để kiểm tra xem docker có đang tải xuống hình ảnh không, hãy chạy:

$ ls -l /var/lib/docker/tmp

trong cụm, hiển thị [các] tệp hình ảnh tạm thời đang được tải xuống, nếu không thì trống.

Nếu bạn đang phát triển trong minikube và sử dụng VPN, docker có thể sử dụng VPN của bạn thông qua fiddler . Đó là, docker sẽ được kết nối với ip: port của fiddler và fiddler được kết nối với VPN. Mặt khác, VPN không được chia sẻ giữa máy chủ của bạn và máy ảo minikube.

— người dùng477273
nguồn

Có một chút bởi lỗi này ngày hôm nay. Vẫn không chắc chắn những gì gây ra nó mặc dù. Mọi thứ đã hoạt động tốt trong một phút và tiếp theo, vấn đề này được cắt bỏ. Cảm ơn bạn đã sửa chữa. Nó làm việc cho tôi.

— Jim

Một lần tôi gặp phải điều này là do các khai báo tài nguyên của tôi vô tình rất nhỏ.

tài nguyên: giới hạn: cpu: bộ nhớ 1000m: 1024M yêu cầu: cpu: bộ nhớ 1000m: 1024M

đấu với

tài nguyên: giới hạn: cpu: bộ nhớ 1000m: 1024m yêu cầu: cpu: bộ nhớ 1000m: 1024m

viết hoa mà m tạo ra sự khác biệt rất lớn trong sử dụng tài nguyên. Tôi đã bị kẹt trên ContainerCreating vì tôi đã không cung cấp đủ bộ nhớ cho container của mình.

— Luis Felipe Moura Pereira De S
nguồn