분류 기타

인증 된 Kubernetes 애플리케이션 개발자가 되는 방법

컨텐츠 정보

  • 조회 386 (작성일 )

본문

이 가이드는 내가 최근에 통과 한 CKAD (Certified Kubernetes Application Developer) 시험에 대한 연구 노트를 요약 한 것입니다.


인증에 관심이 없더라도 이것을 Kubernetes의 원스톱 상점으로 생각하십시오. 모든 주요 기술 개념을 설명하고 무수한 예제를 한 곳에서 확인할 수 있습니다.


또한 시험 준비 및 응시 경험에서 비롯된 몇 가지 추가 사항이 있습니다.


이 글을 쓰는 시점에서 CKAD 커리큘럼 (연구 영역 및 각 영역의 무게)은 다음과 같습니다.

  • 13% – Core Concepts
  • 18% – Configuration
  • 10% – Multi-Container Pods
  • 18% – Observability
  • 20% – Pod Design
  • 13% – Services & Networking
  • 8% – State Persistence

이 가이드는 커리큘럼을 다른 순서로 다룹니다.


쿠버네티스의 기본 (기본적으로 컨테이너와 포드)을 이미 알고 있고 기술을 한 단계 더 높이고 자한다고 가정하겠습니다. 이 시험에 합격하면 이력서가 매우 인기 있는 인증이므로 눈에 띄게 됩니다.


Kubernetes 소개 


Kubernetes는 여러 노드에서 컨테이너화 된 애플리케이션을 쉽게 배포하고 관리 할 수 있는 기술입니다. 가장 눈에 띄는 기능 중 일부는 다음과 같습니다.

  • 컨테이너 구성 및 배포
  • 시스템 모니터링
  • 영구 저장소
  • 자동화 된 스케줄링
  • 자동 확장 및 자동 복구


그리고 훨씬 더.


Kubernetes는 선언적 방식으로 작동합니다. 클러스터에서 원하는 상태를 정의하고 Kubernetes는 클러스터가 항상 해당 상태에 있는지 확인하기 위해 작동합니다.


이 상태를 정의하거나 수정하려면 API 서버와 상호 작용해야 합니다. 이는 다음을 통해 수행 할 수 있습니다.

  • REST calls
  • 명령 줄 도구 kubectl. 여기에서 컴퓨터에 설치하는 방법을 찾을 수 있습니다.

Kubernetes 클러스터에 액세스 할 수 없는 경우 로컬 머신에 minikube를 설치하여 따라가는 것이 좋습니다. 설치 및 시작되면 다음 명령을 실행하여 첫 번째 포드를 만듭니다.


kubectl run --image=busybox --restart=Never --rm -it -- echo "Welcome to Kubernetes!!"

이 포드는 환영 메시지를 인쇄하면 자동으로 삭제됩니다.


Kubernetes에서 클러스터를 관리하는 방법 


클러스터 관리는 CKAD가 되는 커리큘럼의 일부가 아닙니다. 시험을 위해 클러스터를 생성하고 노드를 관리하는 방법 등을 알 필요는 없습니다.


클러스터 관리자가 될 계획이 아니라면 GCP의 GKE 또는 AWS의 EKS와 같이 클라우드에서 관리되는 Kubernetes 버전의 사용자가 될 수 있습니다.


그러나 네임 스페이스, 레이블 및 주석의 개념을 숙지해야 합니다.


네임 스페이스 


네임 스페이스를 사용하면 가상 클러스터를 만들 수 있습니다. 즉, 동일한 물리적 클러스터의 여러 섹션에서 리소스를 분리 할 수 ​​있습니다. 예를 들면 :


  • 개발, 단계, QA 및 프로덕션과 같은 다른 환경을 분리하려면
  • 복잡한 시스템을 더 작은 하위 시스템으로 분해합니다. 프런트 엔드 구성 요소에 대한 네임 스페이스, 백 엔드 구성 요소에 대한 네임 스페이스 등을 만들 수 있습니다.
  • 이름 충돌을 방지하려면 다른 네임 스페이스에서 동일한 이름으로 동일한 리소스를 만들 수 있습니다. 이렇게 하면 동일하게 보이는 다양한 환경 (단계 및 제품을 생각)을 쉽게 만들 수 있습니다.

다음 명령을 실행하여 네임 스페이스를 만들 수 있습니다.


kubectl create ns my-namespace

리소스 할당량 


개발자가 네임 스페이스 (물리적 리소스 및 포드와 같은 Kubernetes 객체 모두)에서 만들 수 있는 리소스의 양을 제한하려는 경우 리소스 할당량을 사용할 수 있습니다.


예를 들어 다음 ResourceQuota를 정의하여 사용자가 클러스터에서 생성 할 수 있는 Kubernetes 보안 비밀의 수를 제한 할 수 있습니다.


apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-quota
spec:
  hard:
    secrets: "2"

파일에서 – my-quota.yaml이라고 부르겠습니다 – 그런 다음 kubectl apply -f my-quota.yaml을 실행하거나 간단히 실행

kubectl create quota my-quota --hard="secrets=2"

나중에 가이드에서 비밀에 대해 자세히 설명합니다.


Labels 


라벨을 사용하면 Kubernetes 클러스터 내에서 리소스를 구성 할 수 있습니다. 라벨은 리소스를 만들 때 또는 기존 리소스에 라벨을 지정하여 리소스에 연결하는 키-값 쌍입니다. 그런 다음 라벨을 사용하여 리소스를 필터링 할 수 있습니다.


예를 들면 :

  • 백엔드 포드 만 표시하려고 합니다. tier = backed 라벨을 포드에 연결 한 다음 (키와 값 모두 임의적이며 원하는 대로 사용할 수 있음) kubectl get pods -l tier = backend를 실행하여 원하는 포드를 검색 할 수 있습니다.
  • 특정 팟 (Pod)과 연관된 배치 또는 서비스를 정의하려고 합니다. 배포 / 서비스에 주시해야 하는 pod를 알려주는 방법은 라벨을 사용하여 선택하는 것입니다.

다음은 몇 가지 일반적인 레이블 관련 작업입니다.

# Labeling a pod, but similar syntax for nodes, etc
kubectl label pods pod-name key=value
# Removing a label by podname
kubectl label pods pod-name label_key-

# Removing a pod using the label as selector
kubectl label po -l app app-

# Display labels
kubectl get pods --show-labels

# Select pods based on their labels (assume we've defined)
kubect get pods -l 'tier in (frontend,backend)'
kubect get pods -l tier=frontend,deployer=coolest-team

주석은 키-값 쌍이라는 점에서 라벨과 유사하지만 리소스를 선택하는 데 사용할 수 없습니다. 그들은 다른 목적을 가지고 있습니다.


주석은 일반적으로 다른 도구에서 처리하기 위해 추가됩니다. 예를 들어 Prometheus를 실행하여 메트릭을 수집하는 경우 이 구성을 설명자에 추가 할 수 있습니다.

metadata:
	labels:
		name: fluentd-elasticsearch
	annotations:
        prometheus.io/scrape: 'true'
        prometheus.io/port: '9102'

Prometheus에게 스크랩 및 포트의 기본값을 각각 true 및 9102로 재정의 하도록 지시합니다.


포드 및 배포를 넘어서 


아시다시피 포드는 Kubernetes의 기본 단위입니다. 대부분의 경우 컨테이너로 생각할 수 있지만 포드는 여러 컨테이너로 구성 될 수 있습니다. 포드는 본질적으로 일시적이므로 기존 포드가 죽을 때 새 포드가 생성되도록 하는 메커니즘이 필요합니다.


배포를 통해 원하는 상태를 정의 할 수 있습니다 (예 : 애플리케이션 복제본 3 개가 항상 실행되도록 함). Kubernetes는 항상 클러스터에서 이 상태를 달성하고 유지하기 위해 노력할 것입니다.


또한 배포를 사용하여 언제든지 실행 중인 복제본 수를 쉽게 관리하고, 롤링 업데이트를 수행하고, 이전 버전으로 롤백하는 등의 작업을 수행 할 수 있습니다.


그러나 더 많은 워크로드가 있습니다.


다중 컨테이너 포드 


포드는 둘 이상의 컨테이너를 실행할 수 있습니다. 컨테이너는 동일한 네트워크에 있고 볼륨을 사용하여 데이터를 공유 할 수 있기 때문에 서로 원활하게 통신 할 수 있습니다.


지금은 다중 컨테이너 포드에 대한 몇 가지 일반적인 디자인 패턴을 살펴 보겠습니다. 이 가이드의 뒷부분에서 볼륨에 대해 자세히 살펴보고 이러한 패턴 중 일부를 배포하는 방법을 살펴 보겠습니다.


Sidecar 


이 패턴에는 기본 컨테이너를 향상 시키기 위해 보조 작업을 실행하는 다른 컨테이너와 함께 기본 애플리케이션을 실행하는 컨테이너가 있습니다.


전형적인 예는 로깅, 모니터링, 포드 볼륨의 데이터 새로 고침, TLS 종료 등과 같은 작업을 처리하는 사이드 컨테이너와 함께 웹 서버 (기본 컨테이너)를 실행하는 것입니다.


Adapter 


마찬가지로 기본 컨테이너와 기본 컨테이너의 출력을 변환하는 보조 컨테이너를 가질 수 있습니다.


예를 들어, 메인 컨테이너가 많은 복잡한 로그를 출력하는 서비스를 실행한다고 가정 해보십시오. 어댑터 컨테이너를 사용하여 로깅 서비스로 전송되기 전에 이 출력을 단순화하여 이 태스크에서 기본 컨테이너 (및 서비스 개발자)를 오프로드 할 수 있습니다.


Ambassador 


또 다른 일반적인 옵션은 보조 컨테이너를 사용하여 기본 컨테이너와 외부 세계 간의 프록시 역할을 하는 것입니다.


예를 들어 테스트 및 프로덕션과 같은 다양한 환경에 대해 다른 데이터베이스가 있을 수 있습니다. 메인 컨테이너에 데이터베이스 연결이 필요한 경우 환경에 따라 적절한 데이터베이스를 찾는 작업을 앰배서더 컨테이너로 오프로드 할 수 있습니다.


Services 


포드는 해당 IP 주소를 사용하여 다른 포드를 연결할 수 있습니다. 그러나 포드는 본질적으로 일시적입니다. 복제 컨트롤러가 있다고 가정하고 죽으면 새 IP 주소로 새 포드가 생성됩니다. 이로 인해 IP를 사용하여 포드에 직접 연결하기가 어렵습니다.


Kubernetes는 고정 IP 주소로 리소스를 만들고 적절한 포드에 요청을 보내는 서비스라는 추상화를 제공합니다.


포드에 직접 연결하는 대신 IP 주소를 통해 서비스에 도달하거나 DNS 서비스 덕분에 정규화 된 이름을 사용하는 것이 더 좋습니다. 또한 일부 서비스 유형은 클러스터 외부에서도 애플리케이션을 노출합니다.


서비스 유형 


만들 수 있는 주요 서비스 유형은 다음과 같습니다.

  • ClusterIP – 클러스터 내부에서 애플리케이션을 노출합니다. 유형을 지정하지 않은 경우 Kubernetes가 만드는 기본 서비스입니다.
  • NodePort – 클러스터의 모든 노드에서 포트를 열어 응용 프로그램을 세계에 노출합니다.
  • LoadBalancer – 클라우드 공급자로드 밸런서를 사용하여 외부에 서비스를 노출합니다.

클러스터 내에서 애플리케이션을 노출하는 방법 


포트 80에서 클러스터의 다른 노드에 애플리케이션 my-app을 노출하려고 한다고 가정 해 보겠습니다. 다음 명령을 사용하여 애플리케이션을 배포하는 배포를 만들 수 있습니다.


kubectl create deploy my-app --image=my-app --port=80

그러면 해당 IP를 통해 클러스터 내의 다른 리소스에서만 액세스 할 수 있는 포드가 생성되며 포드가 다시 시작되면 변경됩니다.


다음 단계는 이러한 포드에 대한 ClusterIP 서비스를 만드는 것입니다. 다음 명령은 포트 80에 도달 할 수 있는 서비스를 만들고 요청을 애플리케이션 (또한 포트 80)에 전달합니다.

kubectl expose deploy my-app --port=80

클러스터 외부에 애플리케이션을 노출하는 방법 


대신 응용 프로그램을 세상에 노출 시키려면 이 구성을 사용하여 NodePort 서비스를 만들 수 있습니다.

kind: Service
apiVersion: v1
metadata:
	name: my-svc
spec:
    type: NodePort
    selector:
	    app: nginx
    ports:
    - protocol: TCP
    	port: 80 # The port where you can reach this service
    	targetPort: 80 # The port that you opened in the pod

Ingress 


서비스가 애플리케이션을 세상에 노출하는 유일한 방법은 아닙니다. Ingress 객체를 클러스터의 진입 점으로 사용할 수도 있습니다.


 외에도 Ingress 객체에 정의 된 규칙을 구현하려면 Nginx와 같은 Ingress 컨트롤러가 필요합니다.


Ingress는 CKAD의 범위를 벗어나므로 다른 주제로 넘어갈 것입니다.


Jobs 


작업은 성공적으로 완료된 경우 다시 시작되지 않는 하나 또는 여러 개의 포드를 생성합니다. 이를 사용하여 일괄 작업, 즉 계산 수행, 일부 파일 백업, 일부 데이터 변환 및 내보내기 등과 같은 일회성 작업을 수행 할 수 있습니다.


달리 명시되지 않는 한 포드는 한 번 실행됩니다. 완료 매개 변수를 사용하여 완료된 것으로 간주되기 위해 작업을 실행해야 하는 횟수를 지정할 수 있습니다. 기본적으로 포드는 순차적으로 실행되지만 병렬로 실행되도록 작업을 설정할 수 있습니다.


성공적으로 완료되지 않은 경우 다시 시작 안 함 (다시 시도)하거나 Kubernetes가 작업이 실패한 것으로 간주하기 전에 OnFailure를 backoffLimit 시간까지 다시 시작하도록 구성 할 수 있습니다.


다음은 명령 줄에서 간단한 작업을 만드는 방법입니다.

kubectl create job my-job --image=busybox -- echo "Hello World"

작업이 성공적으로 실행 된 경우 해당 상태는 COMPLETED가되고 해당 포드는 로그에 액세스 할 수 있도록 삭제되지 않습니다. 다음을 사용하여 볼 수 있습니다.

kubectll get pods --show-all

기본적으로 2 분 후에는 기본 pod 목록에 표시되지 않기 때문입니다.


Cronjobs 


Kubernetes는 Conjobs를 제공하여 주기적으로 또는 미래의 특정 시간 (정기 정리 및 백업 작업, TLS 인증서 갱신 등)에 실행해야 하는 작업을 생성합니다.


Kubernetes는 Cronjob 구성에서 지정한 작업을 수행하기 위해 하나의 작업 만 실행하도록 최선을 다합니다. 그러나 알아야 할 세 가지 일반적인 문제가 있습니다.


  • 작업이 원하는 시간에 정확히 실행된다는 보장은 없습니다. 09:00:00에 작업을 실행해야 한다고 상상해보십시오. startingDeadlineSeconds 속성을 X 초로 설정하여 작업이 09:00:00 + X 초까지 시작되지 않은 경우 실패로 표시되고 실행되지 않도록 할 수 있습니다.
  • 2 작업을 동시에 수행하여 작업을 예약 할 수 있습니다. 이 경우 작업이 멱 등성을 확인해야 합니다. 즉, 작업을 여러 번 수행해도 작업 실행 결과가 변경되지 않습니다.
  • 예약 된 작업이 없습니다. 이 문제를 극복하려면 Cronjob이 이전 실행에서 취소 한 작업을 선택해야 합니다.

다음은 매분 "Hello World"를 출력하는 간단한 cronjob을 만드는 방법입니다.

kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"

cron 일정 표현을 올바르게 하려면 이 웹 사이트를 추천합니다.


다음 3 개의 리소스는 CKAD 시험의 일부가 아니지만 최소한 기본적으로 이해해야 한다고 생각합니다.


Daemon sets 


데몬 세트는 클러스터의 모든 노드에서 포드가 예약되도록 합니다. 이 외에도 포드는 항상 실행 중입니다. 죽거나 누군가 삭제하면 포드가 다시 생성됩니다.


데몬 세트의 일반적인 사용 사례는 각 노드에서 오는 로그 및 메트릭을 수집하는 것입니다. 그러나 아무것도 만들지 않더라도 이미 클러스터에서 실행 중인 데몬 집합이 있습니다. Kubernetes는 모든 노드에서 kube-proxy라는 구성 요소를 실행하는 데몬 집합을 만듭니다!


클러스터에서 노드를 제거하면 이 노드가 이미 데몬 세트를 실행하고 있기 때문에 Kubernetes는 다른 노드에서 데몬을 다시 생성하지 않습니다. 클러스터에 새 노드를 추가하면 데몬 세트가 자동으로 실행됩니다.


Stateful set 


지금까지 우리는 상태 비 저장 애플리케이션 또는 자체 영구 스토리지가 있는 포드를 배포하는 도구를 보았습니다. 상태 저장 응용 프로그램을 배포하려면 상태 저장 집합을 사용할 수 있습니다.


이것은 CKAD 시험의 일부가 아니기 때문에 더 자세한 내용은 다루지 않을 것입니다.


Static pods 


정적 포드는 Kubernetes API가 아니라 kubelet에서 관리하는 포드입니다.


이를 생성하려면 일반 pod 구성 파일을 생성하고 해당 디렉토리를 스캔하도록 kubelet을 구성하기 만하면 됩니다. kubelet을 다시 시작하면 포드가 생성되고 실패하면 다시 시작됩니다.


Kubernetes는 Kubernetes API 서버에있는 pod의 복사 본인 미러 포드를 생성합니다. 이 포드는 kubectl get pods를 실행할 때 나타나는 것을 볼 수 있지만 kubectl delete podName을 사용하여 삭제하려고 하면 정적 포드를 생성 한 노드에서 실행되는 kubelet에 의해 생성 된 포드 목록에 즉시 표시됩니다. 


포드 및 컨테이너를 구성하는 방법 


Kubernetes 클러스터에 배포 할 수 있는 다양한 워크로드를 방금 확인했습니다. 이제 이러한 워크로드를 실행하는 포드 및 컨테이너를 구성하는 방법에 대해 알아 보겠습니다.


Init Containers 


초기화 컨테이너를 사용하여 포드의 볼륨에 일부 데이터를 쓰고 일부 파일을 다운로드하는 등 포드의 초기 상태를 설정할 수 있습니다.


동일한 포드에 대해 하나 이상의 init 컨테이너를 정의 할 수 있습니다. 순차적으로 실행되며 모든 컨테이너가 완료된 후에 만 ​​포드 실행이 시작됩니다. 따라서 init 컨테이너를 사용하여 포드가 실행되기 전에 특정 조건을 기다리도록 할 수도 있습니다.


예를 들어 다른 서비스가 시작되고 실행되기 전에 포드가 대기하도록 할 수 있습니다.


포드 설명의 사양 섹션 아래에 다음과 같은 내용을 추가하여 초기화 컨테이너를 정의 할 수 있습니다.

spec:
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
 ...

ConfigMaps 


애플리케이션 구성을 소스 코드와 별도로 유지하는 것은 따라야 할 관행입니다. ConfigMaps를 사용하면 Kubernetes에서 이를 수행 할 수 있습니다.


ConfigMap은 기밀이 아닌 데이터의 키-값 쌍을 저장하는 데 사용됩니다. 다음 섹션에서는 비밀 데이터 (예 : 암호)를 비밀에 저장하는 방법을 살펴 보겠습니다.


명령 줄에서 ConfigMap을 만들 수 있습니다.

# Passing the values as arguments
kubectl create configmap my-map --from-literal=db_url=my-url --from-literal=username=username

# Passing the values from a file
kubectl create configmap another-map --from-file=my-file

생성 된 애플리케이션은 동일한 네임 스페이스에 있는 포드에서 여러 방법으로 사용할 수 있습니다.

  • As command line arguments
  • As environment variables
  • From a file in a read-only volume


다음 접근 방식을 사용하여 ConfigMap에서 값을 읽는 포드 정의를 살펴 보겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: busybox
      image: busybox
      args:
        - /bin/sh
        - -c
        - "echo $MY_VARIABLE" # This value comes from the configmap
      env:
      - name: MY_VARIABLE
        valueFrom:
          configMapKeyRef:
            name: another-map           
            key: my-key # To load individual keys from a map
      envFrom:
      - configMapRef:
          name: another-map # To import all values from a map as env variables
      volumeMounts:
      - name: config
        mountPath: "/config" # This will contain files with the data stored in my-map
        readOnly: true
  volumes:
    # Name to refer to this volume in the pod
    - name: config
      configMap:
        # Name of the ConfigMap
        name: my-map

Secrets 


비밀은 ConfigMaps와 매우 유사하지만 비밀 데이터를 저장하는 데 사용합니다. 비밀 생성 및 관리는 민감한 주제입니다. 설명서를 반드시 읽으십시오. 여기서 우리는 기본을 볼 것입니다.


비밀을 만드는 가장 간단한 방법은 다음과 같습니다.

#To create a secret from a literal
kubectl create secret generic secret-name --from-literal=password=password
#To create a secret from the content of a file
kubectl create secret generic secret-name --from-file=path-to-file

그런 다음 비밀을 환경 변수 또는 파일로 포드에 마운트 할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: another-pod
spec:
  restartPolicy: Never
  containers:
    - name: busybox
      image: busybox
      args:
        - /bin/sh
        - -c
        - "echo $MY_VARIABLE"
      env:
      - name: MY_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret2
            key: username # To load individual keys from a map
      envFrom:
      - secretRef:
          name: yet-another-secret # To import all values from a map as env variables
      volumeMounts:
      - name: secret-volume
        mountPath: "/secrets" # This will contain files with the data stored in my-map
        readOnly: true
  volumes:
    # Name to refer to this volume in the pod
    - name: secret-volume
      secret:
        # Name of the Secret
        secretName: my-secret

Probes 


프로브를 사용하면 포드가 정상인지, 트래픽을 제공 할 준비가 되었는지, 시작할 준비가 되었는지를 결정하는 규칙을 설정할 수 있습니다. 이 섹션의 끝에서 이러한 몇 가지 프로브와 함께 샘플 설명자를 제시합니다.


활력 프로브 


Kubernetes는 충돌 한 컨테이너를 자동으로 다시 시작합니다. 그러나 이것은 버그 (응용 프로그램의 무한 루프를 상상해보십시오), 교착 상태 등과 같은 상황을 고려하지 않습니다. 활성 상태 프로브를 정의하여 애플리케이션이 정상인지 감지 할 수 있습니다. Kubernetes는 이 프로브를 사용하여 컨테이너를 다시 시작해야 하는지 여부를 결정합니다.


정의 할 수 있는 활성 상태 프로브에는 세 가지 유형이 있습니다.

  • HTTP Get : Kubernetes가 애플리케이션이 정상인지 확인하기 위해 적중 할 수 있는 애플리케이션의 엔드 포인트 (예 : / health)를 정의합니다.
  • 특정 포트에 대한 TCP 연결을 설정하려는 TCP 소켓 프로브. 연결이 설정되지 않으면 응용 프로그램이 다시 시작됩니다.
  • 컨테이너 내부에서 명령을 실행하고 종료 상태 코드가 0과 다른 경우 다시 시작하는 실행 프로브.

Readiness probes 


시작 중에 큰 구성 파일을 로드 해야 하는 서비스를 상상해보십시오. 컨테이너 자체는 정상일 수 있지만 (위에 설명 된 활성 상태 프로브를 사용하여 확인할 수 있음) 요청 수락을 시작할 준비가 되지 않았습니다.


Kubernetes는 준비 상태 프로브를 사용하여 애플리케이션이 트래픽 제공을 시작할 준비가 되었는지 확인합니다.


활성 상태 프로브에 대해 논의 된 많은 아이디어가 준비 상태 프로브에도 적용됩니다.

  • 초기 지연, 시간 초과, 임계 값, 기간 등으로 구성 할 수 있습니다.
  • HTTP get 호출, TCP 소켓 연결 또는 컨테이너 내부 명령 실행을 기반으로 할 수 있습니다.

그러나 활성 상태 프로브는 Kubernetes가 정상 상태가 아닌 경우 컨테이너를 다시 시작하도록 지시하는 반면 준비 상태 프로브는 요청을 수락 할 수 있는 컨테이너 풀에서 컨테이너를 제거하는 데 사용됩니다. 컨테이너가 준비되면 요청 처리를 시작할 수 있습니다.


Startup probes 


시작 프로브는 시작하는 동안에 만 사용됩니다 (예 : 시작 속도가 느린 애플리케이션의 경우). 시작 프로브가 성공하면 활성 상태 및 준비 상태 프로브 (구성된 경우)가 주기적으로 실행되기 시작합니다.


Example 


이 포드는 다음 명령을 실행합니다.

  • sleep 20
  • touch /tmp/healthy
  • sleep 30
  • rm -rf /tmp/healthy
  • sleep 600

프로브를 구성 할 때 알아야 할 가장 기본적인 매개 변수는 다음과 같습니다.

  • 조사를 시작하기 전 initialDelaySeconds
  • 프로브 할 빈도를 정의하는 periodSeconds
  • timeoutSeconds 이후 프로브 시간 초과
  • Kubernetes가 포기한 후 시도 횟수를 결정하는 failureThreshold


구성을 사용하면 포드가 생성 된 후 10 초 후에 프로브가 시작됩니다. 처음 20 초 동안 / tmp / healthy 파일이 존재하지 않습니다. 따라서 준비 상태 프로브가 실패합니다. 그런 다음 해당 파일을 만들고 다음 30 초 동안 파일을 다시 제거 할 때까지 준비 상태 프로브가 성공합니다.


https://www.freecodecamp.org/news/how-to-become-a-certified-kubernetes-application-developer/