Kubernetes에서 배포를 디버깅하는 것은 상당히 어려운 작업일 수 있습니다.어디서부터 시작해요?서비스 아니면 입구?아니면 콩꼬투리 자체?이 세 가지 중 하나라면 어떻게 문제를 해결할 수 있습니까?이 모든 문제들은 디버깅을 필요로 하는 것보다 더 어렵게 할 것이다.
대부분의 디버그 솔루션은 Kubernetes 배포 자체에 기반을 두고 있습니다.Kubernetes가 배포한 구성 요소와 어떻게 서로 연결되는지 알면, 대부분의 배포 문제를 더 잘 해결할 수 있습니다.
다음은 Kubernetes 배포에 대한 기본 지식을 간략하게 설명합니다.

Kubernetes 배포 구성 요소

Kubernetes에 애플리케이션을 배포할 때 일반적으로 다음과 같은 세 가지 구성 요소를 정의합니다.
배포 - 애플리케이션 복제본(Pods)을 만드는 방법입니다.
서비스 - POD로 트래픽을 라우팅하는 내부 로드 밸런서.
입구 - 데이터가 집단 외부에서 귀하의 서비스로 어떻게 흐르는지 설명합니다.
여기에는 빠른 시각적 회고가 있다.

우리의 예시를 위해 간단한 Hello World 응용 프로그램을 배치합시다.
이러한 응용 프로그램의 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를 직접 가리키고 배치를 완전히 건너뛴다.
따라서 Pods와 서비스가 어떻게 서로 관련되어 있는지 주의해야 합니다.
너는 반드시 세 가지 일을 기억해야 한다.

서비스 선택기는 Pod

의 최소 태그와 일치해야 합니다.

서비스targetPort는 기중기

내용기containerPort와 일치해야 한다

서비스port는 모든 숫자가 될 수 있다.여러 서비스는 서로 다른 IP 주소를 할당하기 때문에 같은 포트를 사용할 수 있습니다.

다음 그림에서는 포트 연결 방법에 대해 설명합니다.

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 선택기는요?
그것은 항상 기중기 라벨과 일치해야 하며, 배치원이 기중기를 추적하는 데 사용해야 한다.
만약 당신이 정확한 변경을 했다고 가정한다면, 당신은 어떻게 그것을 테스트합니까?
다음 명령을 사용하여 크레인에 올바른 태그가 있는지 확인할 수 있습니다.

kubectl get pods --show-labels

또는 여러 응용 프로그램에 속하는 pod가 있는 경우:

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

그중any-name=my-app은 라벨any-name: my-app이다.
또 질문 있으세요?
너도 포드에 연결할 수 있어!
kubectl의 port-forward 명령을 사용하여 서비스에 연결하고 연결을 테스트할 수 있습니다.

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

어디:

service/<service name> 은 서비스 이름입니다. - 현재 YAML에서 "내 서비스"

3000은 컴퓨터에서 열고자 하는 포트입니다

80은(는) port 필드

의 서비스 공개 포트입니다.
연결할 수 있으면 올바르게 설정합니다.
만약 안 된다면, 탭이 잘못 놓였거나 포트가 일치하지 않을 가능성이 높습니다.

서비스 및 포털 연결

공개 응용 프로그램의 다음 단계는 입구를 설정하는 것이다.
입구는 서비스를 검색하는 방법을 알고 Pod을 검색하고 데이터를pod로 라우팅해야 합니다.
입구는 이름과 노출된 포트에 따라 정확한 서비스를 검색합니다.
포털과 서비스의 두 가지 일치:

입구의 servicePort 서비스

의 port와 일치해야 한다

입구의 serviceName 서비스

의 name와 일치해야 한다
다음 그림에서는 포트 연결 방법에 대해 설명합니다.

실천 과정에서 다음과 같은 몇 줄을 보셔야 합니다.

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: /

어떻게 입구의 작업 상황을 테스트합니까?kubectl port-forward 이전과 같은 정책을 사용할 수 있지만 서비스에 연결하지 말고 포털 컨트롤러에 연결해야 합니다.
먼저 다음 명령을 사용하여 포털 컨트롤러의 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

입구 기중기 (다른 이름 공간에 있을 수 있음) 를 식별하고 포트를 검색할 수 있도록 설명합니다.

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

마지막으로 Pod에 연결:

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

요청은 컴퓨터의 포트 3000에 액세스할 때마다 포털 컨트롤러 랙의 포트 80으로 전달됩니다.
만약 방문http://localhost:3000하신다면, 이 응용 프로그램이 웹 서비스를 제공하는 것을 발견할 수 있을 것입니다.

회고 포트

다음은 어떤 포트와 태그가 일치해야 하는지 간략하게 살펴보겠습니다.

서비스 선택기는 Pod

의 태그와 일치해야 합니다.

서비스targetPort는 기중기

내용기containerPort와 일치해야 한다

서비스 포트는 모든 숫자가 될 수 있습니다.여러 서비스는 서로 다른 IP 주소를 할당하기 때문에 같은 포트를 사용할 수 있습니다.

입구의 servicePort는 서비스

의 port와 일치해야 한다

서비스 이름은 포털

의 필드serviceName와 일치해야 합니다.
YAML 정의를 구축하는 방법을 이해하는 것은 이야기의 일부일 뿐이다.
문제가 생겼을 때 무슨 일이 일어날까요?
기중기가 작동하지 않았거나 붕괴되고 있을지도 모른다.이 때 당신은 우리의 간소화된 문제 해결 안내서를 참고할 수 있습니다.

3단계 문제 해결 가이드.

Kubernetes 배포에 대한 문제 해결은 배포(POD), 포털, 서비스 등 세 가지 구성 요소를 모두 밑바닥에서 위로 검사해야 합니다.다음은 시각화된 그래픽이 있는 구조화된 안내서입니다. 가능한 모든 배포 문제와 이를 처리하는 방법에 대해 설명합니다. A visual guide on troubleshooting Kubernetes deployments

Reference

이 문제에 관하여(Kubernetes 배포에 문제가 있습니까?기초부터.), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/vikcodes/having-trouble-with-your-kubernetes-deployments-start-with-the-basics-4m02

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

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

Kubernetes 배포에 문제가 있습니까?기초부터.