[CKAD] section 5. Observability

kubernets

 

Observability 라는 단어의 뜻을 번역해보니, 관찰 가능성 혹은 가시성 으로 번역이 된다.

파드의 라이프 사이클과 관련이 있어 보인다.

 

해당 섹션에서는 이 부분을 빠르게 요약해서 넘어가고, 다른 섹션에서 더 상세하게 설명한다고 한다.

 

이 파트에서는 크게 readinessProbe / livenessProbe / Container Log / Monitor 에 대한 것을 배웠다.

 

내용이 꽤 많아보였으나 그렇게 어려운 내용이 아니었다.

 

readinessProbe / livenessProbe 는 서비스가 올라가기 전, 혹은 서비스가 실행 중인 시스템에서 정상 동작하는지 확인을 하기 위해 쓰인다.

 

자바로 실제 운영 배포를 해본 사람들은 알겠지만, 자바의 경우 actuator 를 설정하여 health-check 엔드포인트를 통해 서비스 기동을 확인한다. DB 가 정상적으로 기동하는지, 웹 서비스가 실제로 완전히 기동하게 되고 나서야만 고객에게 서비스를 보여줘야 하기 때문이다.

 

그렇지 않으면 오른쪽 사이트처럼 에러가 보일테니까

 

그래서, 사용 방법을 간단하게 정리해보면 다음과 같다.

 

readinessProbe

• 컨테이너가 기동되기 전 상태를 health-check 를 통해 확인하는 설정

 

spec:
  containers:
  ...
    # http 요청
    readinessProbe:
      httpGet:
        path: /api/ready
        Port: 8080
      initialDelaySeconds : 10
      periodSeconds: 5
      failureThreshold: 8

    # port 확인
    readinessProbe:
      tcpSocket:
        port: 3306

    # 명령어로 확인
    readinessProbe:
      exec:
        command:
        - cat
        - /app/is_ready

 

 

livenessProbe

• 컨테이너가 동작 중인지 확인하기 위한 설정
• 마찬가지로 health-check 를 설정할 수 있다.

 

spec:
  containers:
  ...
    # http 요청
    livenessProbe:
      httpGet:
        path: /api/healthy
        Port: 8080
      initialDelaySeconds : 10
      periodSeconds: 5
      failureThreshold: 8

    # port 확인
    livenessProbe:
      tcpSocket:
        port: 3306

    # 명령어로 확인
    livenessProbe:
      exec:
        command:
        - cat
        - /app/is_ready

​

readinessProbe 와 livenessProbe 는 의도하는 동작이 약간 다르지만, 내용은 거의똑같다.

해당 강의에서는 소개하지 않았지만 startupProbe 라는것이 있는데 readinessProbe 와 비슷하게 시작 직후 바로 실행되는 것 같다.

 

그리고 쿠버네티스의 컨테이너 로그는 다음과 같이 확인이 가능하다.

우선 도커는 다음과 같이 로그를 확인한다.

 

도커

docker run -d kodekloud/event-simulator

docker logs -f ecf

 

쿠버네티스는 다음과 같이 로그를 확인.

 

쿠버네티스

매니페스트 생성 후

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: event-simulator-pod
  name: event-simulator-pod
  namespace: default
spec:
  containers:
  - image: kodekloud/event-simulator
    name: event-simulator1
  - image: kodekloud/event-simulator
    name: event-simulator2

 

아래와 같이 실행하여 로그를 본다.

k logs -f event-simulator-pod

# 멀티 컨테이너의 경우 k logs -f event-simulator-pod -c [컨테이너 이름]

 

 

그리고 마지막으로 모니터

 

모니터링 솔루션 중에는 프로메테우스, 엘라스틱 스택, 데이터 도그, 다이나트레이스, 메트릭스 서버 등의 다양한 솔루션이 있는데,

간단하게 메트릭스 서버를 설치해서 CLI 로 볼 수 있다고 한다.

과거엔 힙스터 라는 모니터링 툴이 있었으나, 지원이 종료된 듯 하다.

 

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml

# replicas 를 2 -> 1 로 변경했다.
$ kubectl edit deployments.apps -n kube-system metrics-server

# 또 검색해보니 - --kubelet-insecure-tls 옵션을 추가하라고 해서 추가해보았다.
...
containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls
...

$ k top nodes

NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
docker-desktop   183m         4%     1423Mi          37%

 

하면 이렇게 확인이 가능.

 

거창해보였던 것과 달리 생각보다 굉장히 기초적인 내용이고 유용한 정보들이었다..

연습문제 이후 Section 6 : Pod Design 에서 계속-