'YAML'에 해당하는 글 2건

파드에서 어플리케이션이 비정상 작동을 할 경우에 대비하여 Liveness/Readiness Probe 를 설정할 수 있다. Liveness Probe 는 컨테이너가 정상적으로 구동 중 인지를 체크할 수 있다. 결과가 정상이 아니면 컨테이너를 재시작한다. Readiness Probe 는 파드가 트래픽을 처리할 준비가 되어 있는지를 체크한다. 결과가 정상이 아니면 해당 파드는 로드밸런스에서 제외된다. 두가지 Probe 에 대하여 설정한 대로 노드의 kubelet 이 주기적으로 상태 체크를 하게 되며, 결과가 비정상일 경우 해당 파드는 not ready 상태로 변경된다. 


아래처럼 readiness/liveness probe 를 가진 파드를 생성해 보자.


apiVersion: v1
kind: Pod
metadata:
  name: "healthy-monolith"
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"
      livenessProbe:
        httpGet:
          path: /healthz
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 15
        timeoutSeconds: 5
      readinessProbe:
        httpGet:
          path: /readiness
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        timeoutSeconds: 1
cs


각 Liveness/Readiness Probe 에 대해서 체크하는 방법으로는 Command / HTTP / TCP 등이 있는데 위 예제에서는 HTTP 를 사용하였다. livenessProbe 의 경우 http://ip:81/healthz 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. readinessProbe 도 마찬가지로 http://ip:81/readiness 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. initialDelaySeconds 는 컨테이너가 준비되고 probe 를 실행하기 까지의 대기 시간이다. periodSeconds 는 probe 체크를 반복할 시간 설정이다. 



Liveness 테스트


아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 컨테이너의 restart 카운팅이 늘어나며, 컨테이너가 자동으로 재시작 될 것이다.


$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
 
$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/healthz/status
$ curl http://127.0.0.1:10081/healthz/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
healthy-monolith   0/1       Running   1         30m
healthy-monolith   1/1       Running   1         30m
healthy-monolith   0/1       Running   2         31m
healthy-monolith   1/1       Running   2         31m
cs



Readiness 테스트


아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 해당 파드는 not ready 상태가 되며 로드밸런스에서 제외되는데, 로드밸런스 테스트는 생략한다 ^^;


$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0          13m
healthy-monolith   0/1       Running   0          16m
healthy-monolith   1/1       Running   0          17m
healthy-monolith   0/1       Running   0          17m
 
$ kubectl describe pods healthy-monolith
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
 
Events:
  Type    Reason     Age   From                                              Message
  ----    ------     ----  ----                                              -------
  Normal  Scheduled  1m    default-scheduler                                 Successfully assigned default/healthy-monolith to gke-bootcamp-default-pool-bb4d9176-tpk5
  Normal  Pulling    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  pulling image "kelseyhightower/monolith:1.0.0"
  Normal  Pulled     1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Successfully pulled image "kelseyhightower/monolith:1.0.0"
  Normal  Created    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Created container
  Normal  Started    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Started container
 Warning  Unhealthy  8s (x15 over 2m)  kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Readiness probe failed: HTTP probe failed with statuscode: 503
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

hello minikube 글에서 어플리케이션 배포부터 노출까지 알아봤었는데 그 때의 배포 명령이 기억 나는가?


$ kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node

deployment.extensions "hello-node" created


위와 같이 kubectl create deployment 명령 다음에 배포에 관련된 정보나 상태 등의 spec 을 inline 으로 나열하였었다. 명령의 이러한 파라미터들은 JSON 형식으로 변환되어 쿠버네티스 API 로 전달된 후 처리된다. 이렇게 kubectl 명령에 inline 으로 파라미터나 플러그 등을 나열하는 것을 명령형(Imperative) 커맨드라고 하며, 주로 일회성 작업을 할 때 사용한다. 나열될 파라미터 수가 적을 때 사용하면 유용하다.


또 한가지 배포에 관련된 정보나 상태 등의 spec 을 상세하게 나열하는 대신 파일(.yaml) 안에 정의하는 방법을 사용할 수도 있는데, 이것을 명령형 오브젝트 구성(Imperative object configuration) 이라고 한다. 다음과 같이 로컬 파일이나 url 상의 파일을 지정하여 사용할 수 있다.


$ kubectl create -f deployment.yaml

$ kubectl create -f https://k8s.io/examples/application/deployment.yaml


위 yaml 예제 파일에는 다음과 같이 3개의 nginx 파드를 생성하는 내용이 담겨 있다.


apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment

  labels:

    app: nginx

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx:1.7.9

        ports:

        - containerPort: 80


.yaml(야믈) 파일은 위처럼 공백 문자를 이용한 들여쓰기로 구조체를 구분하며, 리스트, 해시, 스칼라 데이터의 조합을 모두 표현할 수 있다. 각 항목들을 살펴보면 통신할 api 버전, 생성할 오브젝트 종류, 이름, 식별자, 파드 수, 어플리케이션 이름, 컨테이너 이미지 정보, 연결포트 등이 정의되어 있으며, 쿠버네티스 API 는 이 정의대로 Deployment 를 생성하게 된다. 운영시에는 inline 방식의 명령형 커맨드 보다는 .yaml 파일에 오브젝트를 정의하는 명령형 오브젝트 구성을 주로 사용하게 되며, 위처럼 아주 깔끔하고, 명확하게 오브젝트의 의도를 한눈에 파악할 수 있다. 물론 .yaml 파일을 작성하는 방법이나 오브젝트 정의 방법을 숙지해야 하는 것은 함정!



오브젝트 정의 방법을 간단하게 살펴보자.


쿠버네티스에서 가장 중요한 것은 무엇일까. 아마도 위에 정의한 것 처럼 사용자가 원하는 리소스 및 스펙이 계속해서 유지되는 것이 가장 중요할 것이다. 즉, 사용자가 바라는 상태(desired state) 를 계속해서 유지해야 한다. 배포될 어플리케이션(pod)의 워크로드 정보를 나타내는 클러스터 정보(namespace), 네트워크(service), 디스크 리소스(volume) 를 쿠버네티스의 기본 오브젝트라고 한다. 또한 기본 오브젝트들을 편리하게 관리하기 위한 컨트롤러들이 있다. 파드 복제 수(ReplicaSet), 배포(Deployment), 상태관리API(StatefulSet), 파드를 모든 노드에 복제(DaemonSet), 단일실행(Job) 들이 그것이다. 이러한 오브젝트들은 위와 같이 .yaml 파일에 정의하여 생성/업데이트/삭제 등의 관리를 할 수 있다.


아래는 오브젝트 정의에 필요한 필수 요소이다.

  • apiVersion - 이 오브젝트를 생성하는데 사용할 API 버전
  • kind - 생성할 오브젝트 종류
  • metadata - 오브젝트를 식별할 수 있는 고유 이름
  • spec - 오브젝트 특유의 중첩된 필드를 포함하며, 오브젝트마다 정확한 포맷이 다르므로 관리할 오브젝트의 spec 포맷을 확인한다.


$ kubectl create -f deployment.yaml


위의 deployment 오브젝트 정보를 담은 .yaml 파일을 실행하면 아래와 같이 nginx 를 구동하는 3개의 파드가 생성된 것을 확인할 수 있다.


$ kubectl get pods -o wide

NAME                                READY     STATUS    RESTARTS   AGE       IP            NODE

nginx-deployment-76bf4969df-4tvtv   1/1       Running   0          30m       172.17.0.10   minikube

nginx-deployment-76bf4969df-8d5sk   1/1       Running   0          30m       172.17.0.9    minikube

nginx-deployment-76bf4969df-g6v79   1/1       Running   0          30m       172.17.0.8    minikube





WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret