서론

해당 글은 일프로 님의 인프런 강의 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2의 내용을 정리한 글입니다.

해당 글에 사용된 내용, 사진 및 그림은 모두 강의와 강의 자료에 포함된 내용입니다.

전체 개요

• 노드에 기본적으로 설치되는 컴포넌트
  • kubectl, kubeadm, kubelet
• kubeadm을 통해 마스터 노드에 클러스터를 생성하면 추가되는 컴포넌트
  • Control Plane Component
    • kube-scheduler
    • control-mgmt
    • etcd
    • kube-proxy
    • kube-apiserver
• kubeadm을 통해 워커 노드에 클러스터를 생성하면 추가되는 컴포넌트
  • Worker Component
    • kube-proxy
      • 해당 영역에 사용자 애플리케이션이 관리됨
      • 이전까지 편의를 위해 마스터 노드에 사용자 애플리케이션을 실행시켰지만 마스터 노드가 사용자 애플리케이션으로 인해 죽어버리면 클러스터 전체가 마비되기 때문에 워커 노드에 올려야 함
• Addon Pod
  • 쿠버네티스 기능을 확장하기 위해 사용하는 애플리케이션
    • metrics-serever
    • corends
    • calico
• 마스터 노드에 쿠버네티스 인증서 존재
  • kubectl이 kube-apiserver로 api를 호출해 etcd에 데이터를 저장하는 방식
    • 이로 인해 Object가 저장되고 관리됨
• Object
  • 하나의 인프라 개념으로 단독 기능 수행
  • 네트워크, 볼륨, 환경 변수 등의 요소를 쿠버네티스가 표현하는 방법
  • 종류
    • Service
    • Configmap
    • Secret
    • Pod
    • PVC
• Controller
  • 타 Controller나 Object 제어
  • Object 관리를 자동화시키기 위한 목적
  • 종류
    • HPA
    • Deployment
    • ReplicaSet
• Resource
  • Controller와 Object를 한 번에 칭할 때 표현
  • 종류
    • namespace level resource
    • cluster level resource
      • 예시
        • namespcae
        • pv

각 리소스별 동작

Pod & Probe

1. kube-apiserver가 파드 생성 API를 받음
2. etcd를 통해 데이터 저장
3. Deployment 조회
4. kube-controller-manager는 etcd 데이터베이스를 모니터링하다가 Deployment가 조회되면 ReplicaSet 생성 API 호출
5. ReplicaSet이 생성되면서 Deployment와 Selector로 연결
6. kube-controller-manager가 ReplicaSet에게 파드 생성 API 호출
7. ReplicaSet이 파드 데이터 생성
   7-1. 해당 과정까지 데이터베이스 데이터만 추가된 상황이며, 실제 리소스를 분배해 파드가 생성된 것은 아님
8. kube-scheduler가 노드들에 대한 자원을 kube-apiserver를 통해 모니터링하다가 데이터베이스에 파드 데이터가 있는 것을 확인하면 파드를 띄울 노드 스케줄링
   8-1. 파드 안에 사용자가 설정해 놓은 내용도 참고해 kubelet이 kube-apiserver를 통해 자신의 노드 정보가 있는 파드를 모니터링하다가 스케줄링된 내용을 발견하고 container runtime에 컨테이너 생성 요청
9. containerd가 컨테이너 생성
10. probe 설정으로 인해 kubelet이 컨테이너에게 헬스 체크 API를 주기적으로 호출

Service

1. nodePort로 서비스 연결
2. kubelet이 kube-proxy에게 네트워크 생성 요청
3. kube-proxy가 iptables에 설정 추가
   3-1. 지정한 포트에 맞는 서비스 이름을 매핑하는 룰 업데이트
4. 사용자 요청이 들어온 경우 서비스 이름가 매핑한 포트로 연결
   4-1. 해당 작업을 수행하는 주체는 CNI로 설치한 calico

Secret

• Secret이 제공하는 보안
  • 컨테이너 내부 파일은 노드 메모리 영역에 마운팅
  • 메모리는 전원이 종료되면 지워지는 자원
  • 물리적으로 디스크를 변경할 때 관련 데이터가 남지 않아 복구를 할 수 없음
    • 디스크 탈취 상황에서 보안에 안전
• Secret 내용 수정 시
  • 실시간으로 수정 사항이 반영되지는 않음
  • kubelet이 모니터링하다가 변경 사항을 발견하면 업데이트

HPA

• 컨테이너의 자원 상황은 Container runtime인 containerd가 알고 있는 상황
• kublet이 CPU와 Memory 정보를 일정 주기(10초)로 체크
  • Addon Pod인 metrics-server를 통해 일정 주기(60초)로 사용량을 체크해 kube-controller-manager가 HPA의 임계값과 메트릭을 일정 주기(15초)로 비교하며 스케일링을 발생시킴
    • 수집 구간의 타이밍에 따라 부하 발생 시 즉시 스케일링이 될 수도 있고, 최대 85초까지 걸릴 수도 있음

주요 컴포넌트 로그 확인

# 리소스 확인
kubectl api-resources

• 리소스 이름, 약어, 버전, namespace 리소스 여부, 종류

# 컴포넌트 확인
kubectl get pods -n kube-system

# 컴포넌트 로그 확인
kubectl logs -n kube-system etcd-k8s-master
kubectl logs -n kube-system kube-scheduler-k8s-master
kubectl logs -n kube-system kube-apiserver-k8s-master

• 정상적으로 컴포넌트가 설치되었다면 크게 의미 있는 로그는 없음

# 쿠버네티스 인증서 위치
cd /etc/kubernetes
# 파일 확인 
ls

• amdin.conf가 인증서
• 쿠버네티스 설치 시 해당 인증서를 /root/.kube/config에 복사
• kubectl이 이 인증서를 참조해 API 호출

# 컴포넌트를 띄울 때 사용하는 yaml 파일 디렉토리 
ls /etc/kubernetes/manifests

# 마스터 노드에 있는 모든 파드의 로그가 저장되는 디렉토리
ls /var/log/pods/

• 다음과 같은 네이밍 룰에 의해 생성
  • 전체 파드 로그
    • /var/log/pods/<namespace_<pod-name>_<uid>/<number>.log
  • 특정 파드 로그
    • /var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log
  • 특정 시간대 로그, 특정 문자열 등으로 로그를 탐색할 때 확인
    • Loki, Promtail을 사용하므로 로그 파일을 직접 살펴볼 필요는 없음

에러 발생 시 로그 확인

# kubelet 실행 상태 확인
systemctl status kubelet 

• Active를 통해 현재 상태 확인 가능
  • Running이 아닌 경우 restart 혹은 start를 통해 재실행

# 상세 로그 확인 
# systemctl을 활용해 kubelet 실행에 실패했을 때 상세 로그를 파악하기 위한 용도
journalctl -u kubelet | tail -10

• 로그에서 문제를 확인하고 검색
  • 원인을 찾지 못한 경우 재부팅
    • 재부팅을 해도 안되고, 계속 문제가 발생하는 경우 VM 및 쿠버네티스 재설치
      • 이를 위해 쿠버네티스 설정을 별도로 관리해야 함

# 노드 상태 확인
kubectl get nodes -o wide
kubectl describe node k8s-master

# 파드 상태 확인
kubectl get pods -A -o wide

• 상태가 running이 아닌 것이 있는지 확인

# 이벤트 확인
kubectl get events -A
kubectl events -n anotherclass-123 --types=Normal

• 파드 전체 이벤트 확인

• 특정 파드, 특정 타입의 이벤트 확인

# 애플리케이션 로그 확인
kubectl logs -n anotherclass-123 api-tester-1231-5f488b45b4-7tchq --tail 10
kubectl logs -n anotherclass-123 api-tester-1231-5f488b45b4-7tchq -f
kubectl logs -n anotherclass-123 api-tester-1231-5f488b45b4-7tchq --since=1m

Service 설정 확인

# iptables에서 노드 포트 매핑 내용 확인
iptables -t nat -L KUBE-NODEPORTS -n  | column -t