Kubernetes 환경 에서 의 각종 디 버 깅 방법

저자: Jack 47
옮 겨 싣 는 것 은 작가 와 원문의 출처 를 보존 하 시기 바 랍 니 다.
제 위 챗 공식 계 정 프로그래머 잭 을 주목 해 주 십시오. 양쪽 의 글 이 동기 화 되 고 제 RSS 구독 원 도 추가 할 수 있 습 니 다.
본 고 는 Kubernetes 환경 에서 의 디 버 깅 방법 을 소개 한다.

하나의 용 기 를 시작 할 때 Pod 또는 Replication Controller 를 사용 하지 않 고 하나의 용 기 를 시작 합 니 다.

 
 $ kubectl run webserver --image=nginx

미 러 를 바 꾸 고 싶 은 데 버 전 을 업그레이드 하고 싶 지 않 아 요?수정 할 때마다 미 러 버 전 을 업데이트 해 야 하 는 것 도 귀 찮 습 니 다.새로운 미 러 를 구축 할 때마다 Push 가 Docker Registry 에 갈 때 고정된 버 전 을 사용 한 다음 Kubernetes 가 어떤 미 러 를 시작 할 때 로 컬 에 미 러 가 있 든 없 든 Docker Registry 에 가서 미 러 를 가 져 오 면 됩 니 다.ImagePullPolicy 는 기본 IfNotPresent 에서 Always 로 바 뀌 었 습 니 다.

용기 안의 프로그램 을 직접 수정 하고 싶 고 미 러 를 업데이트 하고 싶 지 않 습 니까?뭐? 그 럴 수 있어?스 크 립 트 를 수정 하거나 바 이 너 리 프로그램 을 직접 바 꾼 다음 docker restart container - id 를 사용 합 니 다.나 는 이때 docker commt 를 사용 하여 수정 사항 을 제출 하려 고 시 도 했 지만 다음 에 시작 할 때 Kubernets 가 잘못 보고 할 것 이다.완전 성 검사 가 있 는 이유 일 겁 니 다.

Pod 가 다시 시작 되 었 습 니 다. 다시 시작 하기 전의 로 그 를 어떻게 봅 니까?아래 명령 은 현재 Pod 의 로그 만 볼 수 있 습 니 다:

$ kubectl logs zookeeper-1

통과 – previous 인 자 는 이전 Pod 의 로그

$ kubectl logs zookeeper-1 --previous

를 볼 수 있 습 니 다.

Pod 라 이 프 사이클 을 보 는 이 벤트 는 다음 명령 을 통 해 명령 말미 이벤트 1 절 을 보고, kubelet 이 APIServer 에 보 낸 Pod 라 이 프 사이클 에서 발생 하 는 이벤트

 
 $ kubectl describe pod podname

를 봅 니 다.

아무 사건 도 보지 못 했 는데 Pod 가 재 개 되 었 다 고요?여전히 describe 명령 을 통 해 Containers. [*]. Last State 부분:

$ kubectl describe pod podname
Name:       kafka-1 
...

Containers:
  kafka:
    ...
    State:      Running
       Started:     Sat, 08 Apr 2017 02:29:04 +0000
    Last State:     Terminated
       Reason:      OOMKilled
      Exit Code:    0
       Started:     Fri, 07 Apr 2017 11:06:56 +0000
      Finished:     Sat, 08 Apr 2017 02:29:04 +0000
    Ready:      True
   Restart Count:   1
...

Kafka - 1 을 볼 수 있 습 니 다. 이 Container 는 메모리 소모 가 너무 많아 메모리 상한 선 (Memory Resource Limit) 에 도달 하여 제거 되 었 습 니 다.Reason: Complete 를 보면 용기 내부 pid 가 1 인 프로그램 이 자발적으로 종료 되 었 음 을 설명 합 니 다.

자원 (CPU / memory) 사용 현황 보기 자원 사용 이 가장 많은 노드

$ kubectl top nodes

자원 사용 이 가장 많은 Pod

$ kubectl top pods

노드 의 자원 사용 현황 보기

$ kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

어떤 Pod 를 떼 어 내 서 Debug 를 하 는 지 label 메커니즘 을 사용 하여 Pod 를 표시 합 니 다.Service 정의 에 status: serving 필드 를 추가 합 니 다.어떤 Pod 를 떼 어 내 서 Debug 를 해 야 하 며 전체 서비스 에 영향 을 주지 않 습 니 다.

 
 $ kubectl get pods --selector="status=serving" 
 $ kubectl label pods webserver-rc-lxag2 --overwrite status=debuging

이때 kubelet 은 이 Pod 를 Service 백 엔 드 목록 에서 삭제 합 니 다.Debug 가 끝나 면 회복 하고 싶 어 요?다시 고치 면 돼 요.

 
 $ kubectl label pods webserver-rc-lxag2 --overwrite status=serving

References:

10 most common reasons kuberntes deployments fail

Kubernetes Community Resources

이 내용에 흥미가 있습니까?

현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:

OpenResty 관련 nginx 및 lua 함수

루 아 코드 를 어떻게 사용 하 는 지 소개 한다.두 가지 방법 이 있 습 니 다.첫 번 째, server 의 location 에 직접 삽입 합 니 다. Nginx subrequest 를 통 해 다른 location...

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.

Kubernetes 환경 에서 의 각종 디 버 깅 방법

좋은 웹페이지 즐겨찾기