Kubernetes 문제 해결을 위한 시각적 가이드

메모. 번역: 이 글은 퍼블릭 도메인에 게재된 프로젝트 자료의 일부입니다. learnk8s, Kubernetes를 사용하여 작업할 수 있도록 회사와 개인 관리자를 교육합니다. 여기에서 프로젝트 관리자인 Daniele Polencic은 K8s 클러스터에서 실행되는 애플리케이션에 일반적인 문제가 발생할 경우 취해야 할 조치에 대한 시각적 지침을 공유합니다.

요약: 다음은 Kubernetes에서 배포를 디버깅하는 데 도움이 되는 다이어그램입니다.

클러스터에서 오류를 찾고 수정하기 위한 순서도입니다. 원본(영어)은 다음에서 구할 수 있습니다. PDF и 그림으로.

Kubernetes에 애플리케이션을 배포할 때 일반적으로 정의해야 하는 세 가지 구성 요소가 있습니다.

• 전개 - 이것은 포드(Pod)라고 불리는 애플리케이션 복사본을 생성하기 위한 일종의 레시피입니다.
• 예배 — 포드 간에 트래픽을 분산하는 내부 로드 밸런서
• 입구 — 트래픽이 외부 세계에서 서비스로 어떻게 전달되는지에 대한 설명.

다음은 간략한 그래픽 요약입니다.

1) Kubernetes에서 애플리케이션은 내부 및 외부의 두 계층의 로드 밸런서를 통해 외부 세계로부터 트래픽을 수신합니다.

2) 내부 밸런서를 서비스라고 하고, 외부 밸런서를 인그레스라고 합니다.

3) 배포는 Pod를 생성하고 모니터링합니다(수동으로 생성되지 않음).

간단한 애플리케이션을 배포하고 싶다고 가정해 보겠습니다. 안녕하세요. 이에 대한 YAML 구성은 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

정의가 꽤 길어서 구성 요소가 서로 어떻게 관련되어 있는지 혼동하기 쉽습니다.

예를 들면 다음과 같습니다

• 언제 포트 80을 사용해야 하고 언제 8080을 사용해야 합니까?
• 충돌하지 않도록 각 서비스에 대해 새 포트를 만들어야 합니까?
• 라벨 이름이 중요합니까? 어디에서나 동일해야 합니까?

디버깅에 집중하기 전에 세 가지 구성 요소가 서로 어떻게 연관되어 있는지 기억해 봅시다. 배포 및 서비스부터 시작해 보겠습니다.

배포와 서비스의 관계

놀라시겠지만 배포와 서비스는 전혀 연결되어 있지 않습니다. 대신 서비스는 배포를 우회하여 Pod를 직접 가리킵니다.

따라서 우리는 Pod와 서비스가 서로 어떻게 관련되어 있는지에 관심이 있습니다. 기억해야 할 세 가지:

1. 선택기(selector) 서비스의 경우 하나 이상의 Pod 라벨과 일치해야 합니다.
2. targetPort 일치해야합니다 containerPort Pod 내부의 컨테이너입니다.
3. port 서비스는 무엇이든 될 수 있습니다. 서로 다른 서비스는 IP 주소가 다르기 때문에 동일한 포트를 사용할 수 있습니다.

다음 다이어그램은 위의 모든 내용을 그래픽 형식으로 나타냅니다.

1) 서비스가 특정 포드로 트래픽을 전달한다고 상상해 보세요.

2) 포드를 생성할 때 다음을 지정해야 합니다. containerPort 포드의 각 컨테이너에 대해 다음을 수행합니다.

3) 서비스를 생성할 때 다음을 지정해야 합니다. port и targetPort. 그러나 컨테이너에 연결하는 데 어느 것이 사용됩니까?

4) 를 통해 targetPort. 일치해야 합니다. containerPort.

5) 컨테이너에 포트 3000이 열려 있다고 가정하면 값이 targetPort 동일해야합니다.

YAML 파일에서 라벨과 ports / targetPort 일치해야합니다:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

라벨은 어떻습니까? track: canary 배포 섹션 상단에 있습니까? 일치해야 할까요?

이 레이블은 배포에 따라 다르며 서비스에서 트래픽을 라우팅하는 데 사용되지 않습니다. 즉, 제거하거나 다른 값을 할당할 수 있습니다.

선택자는 어떻습니까? matchLabels?

항상 Pod 라벨과 일치해야 합니다., 이는 배포에서 포드를 추적하는 데 사용되기 때문입니다.

올바른 편집을 했다고 가정해 보겠습니다. 어떻게 확인하나요?

다음 명령을 사용하여 Pod 레이블을 확인할 수 있습니다.

kubectl get pods --show-labels

또는 포드가 여러 애플리케이션에 속하는 경우:

kubectl get pods --selector any-name=my-app --show-labels

Где any-name=my-app 라벨입니다 any-name: my-app.

남은 어려움이 있나요?

포드에 연결할 수 있습니다! 이렇게 하려면 다음 명령을 사용해야 합니다. port-forward kubectl에서. 이를 통해 서비스에 연결하고 연결을 확인할 수 있습니다.

kubectl port-forward service/<service name> 3000:80

Здесь :

• service/<service name> - 서비스 이름; 우리의 경우에는 그렇지 my-service;
• 3000은 컴퓨터에서 열어야 하는 포트입니다.
• 80 - 필드에 지정된 포트 port 서비스.

연결이 설정되면 설정이 올바른 것입니다.

연결에 실패하면 레이블에 문제가 있거나 포트가 일치하지 않는 것입니다.

서비스와 인그레스의 관계

애플리케이션에 대한 액세스를 제공하는 다음 단계에는 Ingress 설정이 포함됩니다. Ingress는 서비스를 찾는 방법을 알아야 하고, Pod를 찾아 해당 서비스로 트래픽을 전달해야 합니다. Ingress는 이름과 열린 포트로 필요한 서비스를 찾습니다.

수신 및 서비스 설명에서 두 매개변수가 일치해야 합니다.

1. servicePort Ingress에서는 매개변수와 일치해야 합니다. port 서비스 중;
2. serviceName Ingress에서는 필드와 일치해야 합니다. name 서비스 중.

다음 다이어그램은 포트 연결을 요약합니다.

1) 이미 알고 있듯이 서비스는 특정 port:

2) Ingress에는 다음과 같은 매개변수가 있습니다. servicePort:

3) 이 매개변수(servicePort)는 항상 일치해야 합니다. port 서비스 정의에서:

4) 서비스에 포트 80이 지정된 경우 다음이 필요합니다. servicePort 또한 80과 동일했습니다.

실제로는 다음 줄에 주의해야 합니다.

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

Ingress가 실행 중인지 확인하는 방법은 무엇입니까?

이 방법을 다음과 함께 사용할 수 있습니다. kubectl port-forward하지만 서비스 대신 Ingress 컨트롤러에 연결해야 합니다.

먼저 Ingress 컨트롤러를 사용하여 Pod의 이름을 찾아야 합니다.

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Ingress Pod(다른 네임스페이스에 있을 수 있음)를 찾아 다음 명령을 실행합니다. describe포트 번호를 찾으려면 다음을 수행하십시오.

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

마지막으로 포드에 연결합니다.

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

이제 컴퓨터의 포트 3000으로 요청을 보낼 때마다 Ingress 컨트롤러를 통해 포드의 포트 80으로 전달됩니다. 로 가면서 http://localhost:3000을 클릭하면 애플리케이션에서 생성된 페이지가 표시됩니다.

포트 요약

어떤 포트와 레이블이 일치해야 하는지 다시 한 번 기억해 봅시다.

1. 서비스 정의의 선택기는 Pod의 레이블과 일치해야 합니다.
2. targetPort 정의에 따르면 서비스는 일치해야 합니다. containerPort 포드 내부의 컨테이너;
3. port 정의에서 서비스는 무엇이든 될 수 있습니다. 서로 다른 서비스는 IP 주소가 다르기 때문에 동일한 포트를 사용할 수 있습니다.
4. servicePort 인그레스는 일치해야 합니다. port 서비스의 정의에서;
5. 서비스 이름은 필드와 일치해야 합니다. serviceName 인그레스에서.

안타깝게도 YAML 구성을 적절하게 구성하는 방법을 아는 것만으로는 충분하지 않습니다.

일이 잘못되면 어떻게 되나요?

포드가 시작되지 않거나 충돌할 수 있습니다.

Kubernetes에서 애플리케이션 문제를 진단하는 3단계

배포 디버깅을 시작하기 전에 Kubernetes 작동 방식을 잘 이해해야 합니다.

K8s에 다운로드된 각 애플리케이션에는 세 가지 구성 요소가 있으므로 맨 아래부터 시작하여 특정 순서에 따라 디버깅해야 합니다.

1. 먼저 포드가 작동하는지 확인한 다음...
2. 서비스가 Pod에 트래픽을 공급하는지 확인한 후...
3. Ingress가 올바르게 구성되었는지 확인하세요.

시각적 표현:

1) 문제는 맨 밑바닥부터 찾기 시작해야 합니다. 먼저 포드에 상태가 있는지 확인하세요. Ready и Running:

2) 포드가 준비되면(Ready), 서비스가 포드 간에 트래픽을 분산하는지 여부를 확인해야 합니다.

3) 마지막으로 서비스와 Ingress 간의 연결을 분석해야 합니다.

1. 포드 진단

대부분의 경우 문제는 포드와 관련이 있습니다. Pod가 다음과 같이 나열되어 있는지 확인하세요. Ready и Running. 다음 명령을 사용하여 이를 확인할 수 있습니다.

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

위 명령 출력에서 ​​마지막 Pod는 다음과 같이 나열됩니다. Running и Ready그러나 다른 두 사람의 경우에는 그렇지 않습니다.

무엇이 잘못되었는지 이해하는 방법은 무엇입니까?

포드 진단에 유용한 네 가지 명령이 있습니다.

1. kubectl logs <имя pod'а> 포드의 컨테이너에서 로그를 추출할 수 있습니다.
2. kubectl describe pod <имя pod'а> 포드와 관련된 이벤트 목록을 볼 수 있습니다.
3. kubectl get pod <имя pod'а> Kubernetes에 저장된 포드의 YAML 구성을 가져올 수 있습니다.
4. kubectl exec -ti <имя pod'а> bash 포드 컨테이너 중 하나에서 대화형 명령 셸을 시작할 수 있습니다.

어느 것을 선택해야 합니까?

사실은 보편적인 명령이 없다는 것입니다. 이들의 조합을 사용해야 합니다.

일반적인 포드 문제

포드 오류에는 시작 오류와 런타임 오류라는 두 가지 주요 유형이 있습니다.

시작 오류:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

런타임 오류:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

일부 오류는 다른 오류보다 더 일반적입니다. 다음은 가장 일반적인 오류 중 일부와 이를 해결하는 방법입니다.

이미지풀백해제

이 오류는 Kubernetes가 포드 컨테이너 중 하나에 대한 이미지를 얻을 수 없을 때 발생합니다. 이에 대한 가장 일반적인 세 ​​가지 이유는 다음과 같습니다.

1. 이미지 이름이 잘못되었습니다. 예를 들어, 이름에 실수가 있거나 이미지가 존재하지 않습니다.
2. 이미지에 존재하지 않는 태그가 지정되었습니다.
3. 이미지는 개인 레지스트리에 저장되며 Kubernetes에는 해당 이미지에 액세스할 수 있는 권한이 없습니다.

처음 두 가지 이유는 제거하기 쉽습니다. 이미지 이름과 태그만 수정하면 됩니다. 후자의 경우 Secret에 닫힌 레지스트리에 대한 자격 증명을 입력하고 Pod에 링크를 추가해야 합니다. Kubernetes 문서에서 예가 있다 이것이 어떻게 이루어질 수 있습니까?

충돌 루프 백오프

Kubenetes에서 오류가 발생합니다. CrashLoopBackOff, 컨테이너를 시작할 수 없는 경우. 이는 일반적으로 다음과 같은 경우에 발생합니다.

1. 애플리케이션 실행을 방해하는 버그가 애플리케이션에 있습니다.
2. 컨테이너 잘못 구성됨;
3. 활성 테스트가 너무 여러 번 실패했습니다.

실패 이유를 찾으려면 컨테이너의 로그에 액세스해야 합니다. 컨테이너가 너무 빨리 다시 시작되어 로그에 액세스하기 어려운 경우 다음 명령을 사용할 수 있습니다.

kubectl logs <pod-name> --previous

이전 컨테이너 구현의 오류 메시지를 표시합니다.

실행컨테이너 오류

이 오류는 컨테이너가 시작되지 않을 때 발생합니다. 애플리케이션이 실행되기 전의 순간에 해당합니다. 일반적으로 다음과 같은 잘못된 설정으로 인해 발생합니다.

• ConfigMap 또는 Secrets와 같이 존재하지 않는 볼륨을 마운트하려고 시도합니다.
• 읽기 전용 볼륨을 읽기-쓰기로 마운트하려는 시도입니다.

팀은 이러한 오류를 분석하는 데 매우 적합합니다. kubectl describe pod <pod-name>.

포드가 보류 중 상태입니다.

생성된 포드는 해당 상태로 유지됩니다. Pending.

왜 이런 일이 일어나는 걸까요?

가능한 이유는 다음과 같습니다(스케줄러가 제대로 작동한다고 가정합니다).

1. 클러스터에 처리 능력, 메모리 등 Pod를 실행하는 데 필요한 리소스가 부족합니다.
2. 개체가 적절한 네임스페이스에 설치됩니다. ResourceQuota 포드를 생성하면 네임스페이스가 할당량을 초과하게 됩니다.
3. 포드가 보류 중으로 바인딩되었습니다. PersistentVolumeClaim.

이 경우 다음 명령을 사용하는 것이 좋습니다. kubectl describe 그리고 해당 부분을 확인해보세요 Events:

kubectl describe pod <pod name>

관련된 오류가 발생한 경우 ResourceQuotas, 다음 명령을 사용하여 클러스터 로그를 보는 것이 좋습니다.

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

포드가 준비되지 않았습니다.

Pod가 다음과 같이 나열되어 있는 경우 Running, 하지만 상태가 아닙니다. Ready, 준비 상태를 확인하는 것을 의미합니다. (준비 상태 프로브) 실패합니다.

이 경우 포드는 서비스에 연결되지 않으며 트래픽이 서비스로 흐르지 않습니다. 준비 테스트 실패는 애플리케이션 문제로 인해 발생합니다. 이 경우 오류를 찾으려면 해당 섹션을 분석해야 합니다. Events 명령 출력에서 kubectl describe.

2. 서비스 진단

포드가 다음과 같이 나열되는 경우 Running и Ready, 하지만 여전히 애플리케이션에서 응답이 없으면 서비스 설정을 확인해야 합니다.

서비스는 라벨에 따라 트래픽을 Pod로 라우팅하는 역할을 담당합니다. 따라서 가장 먼저 해야 할 일은 서비스에서 작동하는 포드 수를 확인하는 것입니다. 이렇게 하려면 서비스에서 엔드포인트를 확인하면 됩니다.

kubectl describe service <service-name> | grep Endpoints

끝점은 다음 형식의 값 쌍입니다. <IP-адрес:порт>, 출력에는 그러한 쌍이 하나 이상 있어야 합니다(즉, 하나 이상의 Pod가 서비스와 작동함).

만약 섹션 Endpoins 비어 있으면 두 가지 옵션이 가능합니다.

1. 올바른 라벨이 있는 Pod가 없습니다(힌트: 네임스페이스가 올바르게 선택되었는지 확인하세요).
2. 선택기의 서비스 라벨에 오류가 있습니다.

엔드포인트 목록이 표시되지만 여전히 애플리케이션에 액세스할 수 없다면 원인은 다음의 버그일 가능성이 높습니다. targetPort 서비스 설명에.

서비스 기능을 확인하는 방법은 무엇입니까?

서비스 유형에 관계없이 다음 명령을 사용할 수 있습니다. kubectl port-forward 연결하려면:

kubectl port-forward service/<service-name> 3000:80

Здесь :

• <service-name> - 서비스 이름;
• 3000은 컴퓨터에서 여는 포트입니다.
• 80 - 서비스 측 포트입니다.

3. 진입 진단

여기까지 읽었다면 다음을 수행하십시오.

• 포드는 다음과 같이 나열됩니다. Running и Ready;
• 서비스는 포드 간에 트래픽을 성공적으로 분산합니다.

그러나 여전히 앱에 접근할 수 없습니다.

이는 수신 컨트롤러가 올바르게 구성되지 않았을 가능성이 높다는 것을 의미합니다. Ingress 컨트롤러는 클러스터의 타사 구성 요소이므로 유형에 따라 디버깅 방법이 다릅니다.

그러나 Ingress를 구성하기 위해 특수 도구를 사용하기 전에 매우 간단한 작업을 수행할 수 있습니다. 인그레스 용도 serviceName и servicePort 서비스에 연결합니다. 올바르게 구성되었는지 확인해야 합니다. 다음 명령을 사용하여 이 작업을 수행할 수 있습니다.

kubectl describe ingress <ingress-name>

열인 경우 Backend 비어 있으면 구성 오류가 발생할 확률이 높습니다. 백엔드가 제자리에 있지만 여전히 애플리케이션에 액세스할 수 없는 경우 문제는 다음과 관련될 수 있습니다.

• 공용 인터넷에서 수신 접근성 설정
• 공용 인터넷의 클러스터 접근성 설정.

Ingress Pod에 직접 연결하여 인프라 문제를 식별할 수 있습니다. 이렇게 하려면 먼저 Ingress Controller Pod를 찾으세요(다른 네임스페이스에 있을 수 있음).

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

명령을 사용하십시오 describe포트를 설정하려면:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

마지막으로 포드에 연결합니다.

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

이제 컴퓨터의 포트 3000에 대한 모든 요청이 포드의 포트 80으로 리디렉션됩니다.

이제 작동합니까?

• 그렇다면 문제는 인프라에 있습니다. 트래픽이 클러스터로 어떻게 라우팅되는지 정확히 알아내는 것이 필요합니다.
• 그렇지 않다면 Ingress 컨트롤러에 문제가 있는 것입니다.

Ingress 컨트롤러가 작동하지 않으면 디버깅해야 합니다.

Ingress 컨트롤러에는 다양한 종류가 있습니다. 가장 인기 있는 것은 Nginx, HAProxy, Traefik 등입니다. (기존 솔루션에 대한 자세한 내용은 다음을 참조하세요. 우리의 리뷰 - 대략. 번역) 관련 컨트롤러 설명서의 문제 해결 가이드를 참조해야 합니다. 왜냐하면 인그레스 Nginx 가장 널리 사용되는 Ingress 컨트롤러이므로 이와 관련된 문제를 해결하기 위한 몇 가지 팁을 기사에 포함했습니다.

Ingress Nginx 컨트롤러 디버깅

Ingress-nginx 프로젝트에는 공식 kubectl용 플러그인. 팀 kubectl ingress-nginx 다음 용도로 사용할 수 있습니다.

• 로그, 백엔드, 인증서 등 분석
• Ingress에 대한 연결
• 현재 구성을 연구하고 있습니다.

다음 세 가지 명령이 도움이 될 것입니다.

• kubectl ingress-nginx lint — 확인 nginx.conf;
• kubectl ingress-nginx backend — 백엔드를 탐색합니다(와 비슷함). kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — 로그를 확인합니다.

어떤 경우에는 플래그를 사용하여 Ingress 컨트롤러에 대한 올바른 네임스페이스를 지정해야 할 수도 있습니다. --namespace <name>.

개요

어디서부터 시작해야 할지 모르면 Kubernetes 문제 해결이 어려울 수 있습니다. 항상 상향식으로 문제에 접근해야 합니다. 즉, Pod로 시작한 다음 서비스와 Ingress로 이동해야 합니다. 이 문서에 설명된 디버깅 기술은 다음과 같은 다른 개체에 적용될 수 있습니다.

• 유휴 작업 및 CronJobs
• StatefulSet 및 DaemonSet.

감사의 마음을 전합니다 게르게리 리스크코, 다니엘 웨이블 и 찰스 크리스티라지 귀중한 의견과 추가 사항을 위해.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes 포드에서 디버깅을 위한 kubectl-debug 플러그인";
• «쿠버네티스 운영의 재미있는 시스템 버그 6가지 [및 해당 솔루션]";
• «Kubernetes에서 실행되는 애플리케이션 개발자를 위한 도구";
• «SRE 일상생활에 대한 6가지 실용적인 이야기 ".

출처 : habr.com