[Kubernetes] Probe, Resource Limits

 

 

 

컨테이너가 Running 이라고 해서 항상 정상 작동하지는 않는다. 

앱이 떠 있지만 내부적으로 멈춰서 요청을 못 받을 수 있고, 앱이 뜨는 도중 요청이 들어올 수 있음. 

그러니 Probe를 사용한다.

 

프로토스에서 미네랄 캐는 일꾼이 Probe인데 여기서도 나름 비슷함.. 컨테이너가 잘 살아있는지 조사하는 역할을 수행한다. 

종류는 세 개

 

1. livenessProbe

컨테이너가 살아있는지를 검사하고 실패하면 컨테이너를 재시작한다.

앱이 응답하는지 확인하고 재시작시킴.

 

2. readinessProbe 

컨테이너가 요청 받을 준비가 됐는지를 검사한다. 

실패하면 서비스에서 제외하고 트래픽을 보내지 않음.

 

3. startupProbe

시작이 느린 앱의 startup이 끝날 때 까지 다른 probe를 미룬다. 

 

httpGet으로 HTTP 요청을 보내거나 tcpSocket으로 특정 포트가 열려있는지 확인하거나 exec으로 명령을 실행해보는 식으로 확인.

 

 

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
  namespace: ts
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        resources: {}
status: {}

 

 

nginx에 probe를 붙였다. 명령어로는 못 붙이니 dry-run 으로 추가하는 식으로 YAML을 다뤄야 함. 

READY 0/1 이면 probe가 실패하고 있을 수 있으니 확인해봐야함. probe 포트를 잘못 설정하는 경우도 있으니 주의하자. 

 

 

 

---

 

 

컨테이너를 그냥 띄우면 자원 제한이 없어서 Pod 하나가 메모리를 다 먹으면 다른 Pod가 제대로 동작하지 못한다. 

버그로 Pod 하나가 CPU를 100% 차지하며 노드 전체가 느려지기도 함. 

 

그러니 특정 컨테이너마다 자원 사용량을 정해줄 수 있다. 이 때 Resources를 사용함. 

정상 작동에 필요한 최소량과 쓸 수 있는 최대량을 명시한다. 

 

CPU에서 1은 1코어이고 500m은 0.5코어를 의미 

메모리 단위는 PVC 단위와 똑같다. 

 

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: limited
  name: limited
  namespace: ts
spec:
  replicas: 1
  selector:
    matchLabels:
      app: limited
  strategy: {}
  template:
    metadata:
      labels:
        app: limited
    spec:
      containers:
      - image: nginx
        name: nginx
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
status: {}

 

 

노드에 남은 메모리가 1Gi일때 Pod가 2Gi를 요구한다면 배치할 수 없어서 Pending 상태가 된다. 

이러면 requests를 줄이거나 노드를 늘려야 함. 

STATUS가 Insufficient CPU/Memory거나 OOMKilled로 재시작된다면 resources를 확인하자.

 

QoS Class 부분이 BestEffort라면 자원 설정이 아예 없다는 뜻으로 requests도 없고 limits도 없음을 의미함.

resources가 적용되지 않으면 저렇게 뜬다. 

 

 

 

---

 

 

 

Pod 안에 여러 컨테이너를 넣는 경우도 있다.

Pod는 IP 하나를 공유하고 컨테이너들은 localhost와 포트번호로 서로를 구분한다. 

 

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-demo
  namespace: ts
spec:
  containers:
  - name: writer
    image: busybox
    command: ["sh", "-c", "while true; do echo $(date) >> /shared/log.txt; sleep 5; done"]
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  - name: reader
    image: busybox
    command: ["sh", "-c", "sleep 10; tail -f /shared/log.txt"]
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  volumes:
  - name: shared-data
    emptyDir: {}

 

 

 

containers 아래에 컨테이너가 두 개 있다. 

emptyDir은 Pod가 살아있는 동안만 존재하는 공간으로 Pod의 컨테이너들이 파일을 주고받을 때 사용한다. PVC처럼 영구는 아님. 

 

k logs <pod> -c <컨테이너> -n ns

k exec -it <pod> -c <컨테이너> -n ns -- sh

멀티컨테이너에서 특정 컨테이너의 로그를 확인할 때는 -c 옵션을 사용해 컨테이너명도 지정해 줘야 한다. 

특정 컨테이너로 진입할 때도 마찬가지 

 

컨테이너 명을 모르는 경우 describe 명령어로 보면 됨. 

 

13months@13monthsBook k8s % k get pods -n ts
NAME           READY   STATUS    RESTARTS   AGE
sidecar-demo   2/2     Running   0          74s

 

 

YAML에서 kind: Pod으로 지정했으니 뒤에 무작위 시드가 붙지 않는다. 

즉, Pod 이름만 봐도 어떻게 만들어졌는지 알 수 있음. 

 

init container는 메인 컨테이너보다 먼저 실행되고 실행이 끝나야 메인이 시작되는 컨테이너이다.

 

 

13months@13monthsBook k8s % kubectl run init-demo -n ts --image=busybox \
> --dry-run=client -o yaml > pod.yaml
13months@13monthsBook k8s % vim pod.yaml 
13months@13monthsBook k8s % cat pod
cat: pod: No such file or directory
13months@13monthsBook k8s % cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: init-demo
  name: init-demo
  namespace: ts
spec:
  volumes:
  - name: work-volume
    emptyDir: {}
  initContainers:
  - name: setup
    image: busybox
    command: ['sh', '-c', 'echo initialized > /work/data.txt']
    volumeMounts:
    - name: work-volume
      mountPath: /work
  containers:
  - image: busybox
    command: ['sh', '-c', 'cat /work/data.txt && sleep 3600']
    volumeMounts:
    - name: work-volume
      mountPath: /work
    name: init-demo
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
13months@13monthsBook k8s % kubectl apply -f pod.yaml 
pod/init-demo created
13months@13monthsBook k8s % k get pod -n ts
NAME           READY   STATUS    RESTARTS   AGE
init-demo      1/1     Running   0          25s
sidecar-demo   2/2     Running   0          30m
13months@13monthsBook k8s % k logs init-demo -n ts
Defaulted container "init-demo" out of: init-demo, setup (init)
initialized
13months@13monthsBook k8s %

 

kubectl 에서의 -c는 컨테이너를 고를 때 사용하고, sh에서의 -c는 문자열을 명령으로 실행하라는 옵션이다. 

많이 쳐보기....  YAML...