쿠버네티스 개념

Kubernetes Concept

Kubernetes

• 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 오케스트레이션 시스템
• 사용 이유
  • 서버 자원을 효율적으로 사용하면 대규모 서비스를 운영하는 기업들은 큰 비용 절감 효과
  • 여러 서비스에서 서버 자원을 공유해서 사용 가능

 

VM vs Container

• VM 가상화는 별도의 Guest OS를 가지고 실행함
• 컨테이너는 Host OS의 커널을 공유하기 때문에 가볍고 VM보다 더 높은 성능을 제공

 

Container Runtime

• 컨테이너를 실행하고 관리하는데 사용되는 소프트웨어 (Docker, containerd, CRI-O)
• k8s에서는 v1.23까지만 Docker를 지원하고 그 이후 버전에서 deprecated, 도커보다 간결한 아키텍처를 갖은 containerd를 사용

 

Kubernetes 용어

• Node: k8s의 워커 역할
• Pod: k8s의 최소 배포 단위로서, 하나 이상의 컨테이너(도커 컨테이너 포함)를 포함하고 이들을 관리
• Service: 외부에서 pod에 접근을 위한 연결
• Namespace: k8s에서 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상적 개념
• ResourceQuota: 각 네임스페이스의 전체 리소스를 제한
• LimitRange: 컨테이너나 파드의 리소스 제한
• ConfigMap: 설정 정보를 정의하고 Pod에 전달
• Secrets: 암호,토큰과 같은 중요 데이터를 포함하는 오브젝트
• Controller: 클러스터의 상태를 관찰하고 필요한 경우에 파드의 생성 또는 변경을 요청하는 컨트롤 루프
  • Replication Controller(Deprecated), ReplicatSet: 파드가 죽으면 감지해서 복구, 스케일 인-아웃, 실행할 파드의 개수를 지정할 수 있고 지정한 개수만큼 파드가 유지되도록 관리
  • Deployment: 배포 후에 파드를 새 버전으로 업그레이드, 업그레이드 문제 발생시 쉽게 롤백
  • DaemonSet: 한 노드의 파드가 하나만 유지 (Prometheus - 성능 수집, fluentd - 로그 수집, GlusterFS - 스토리지 구성)
  • CronJob: Job을 주기적으로 실행 (Job은 특정 작업만 실행 후 종료)
    
    

Architecture

Kubernetes Architecture

• Control Plane (master)
  • API 서버 (kube-api-server): 쿠버네티스 API를 제공하며, 클러스터 관리의 중심 역할
  • 스케줄러 (kube-scheduler): 파드(Pod)를 노드에 할당하는 역할
  • 컨트롤러 매니저 (kube-controller-manager): 다양한 컨트롤러를 실행. 이들 컨트롤러는 복제 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러 등을 포함
  • etcd: 모든 클러스터 데이터를 저장하는 일관성 있는 키-값 저장소

• Node (worker)
  
  • container runtime: 컨테이너를 실행하는 런타임 (docker, containerd, cri-o)
  • kubelet: api-server에 의해 할당된 파드를 실행하고 관리하는 역할
  • kube-proxy: 각 노드의 네트워크 프록시 기능을 제공하여 파드 간의 네트워크를 관리

 

Kubernetes Cluster Architecture

• Networking
  • Pod Network 
    • Pause Container: 파드 내의 컨테이너 간 통신을 관리
    • CNI Plugin: 노드 내,외 파드간의 통신을 관리
      • CNI(Container Network Interface)는 컨테이너가 생성될 때 네트워크 인터페이스를 구성하고 관리하는 역할
        • Calico, Weavenet, Flannel
      • kubenet 이라는 자체 플러그인을 제공하지만 네트워크 기능이 제한적인 단점으로, 3rd-party 플러그인을 사용
  • Service Network
    • 서비스를 파드나 CNI에 연결해서 서비스를 통해 파드로 통신
• Storage
  • hostPath로 내부 노드 볼륨을 사용하는 방법
  • 외부 클라우드 스토리지로 구성하는 방법
  • 내부 클러스터에 3rd-party 스토리지 솔루션을 구성하는 방법
• Logging
  
  • Core Pipeline
    • 쿠버네티스 자체 기능(CLI)으로 로깅
    • metric-server로 각 노드의 모니터링 정보가 수집
      • kubectl top, kubectl log CLI 명령을 통해 모니터링
  • Service Pipeline
    • 별도의 플러그인을 설치해서 구성
      • 모니터링 관련된 파드들이 생성됨 > 파드들이 각각의 노드에서 서버로 로그를 수집 > 해당 정보들을 UI를 통해 사용자에게 제공
        
        

Object

Pod

• 파드는 k8s의 최소 배포 단위로서, 하나 이상의 컨테이너(도커 컨테이너 포함)를 포함하고 이들을 관리
• 파드내의 컨테이너들은 포트 중복될 수 없음
• 파드를 생성하면 ip는 자동 할당되고 휘발성의 특징을 가짐 (클러스터 내에서만 접근 가능)
• Label
  • key-value 형태로 파드 사용 목적을 구분하고 파드의 라벨을 서비스에서 selector로 연결 가능
• Node Schedule
  • 파드를 만들 때 노드를 직접 선택 (nodeSelector 명시)
  • 쿠버네티스 스케줄러가 노드를 지정 (request,limit 메모리 지정 가능)

Service

• 서비스는 pod에 접근을 위한 연결을 제공

•  ClusterIP
  • 파드는 성능이나 시스템 장애로 재생성되면 파드의 ip가 변경되어 신뢰성이 떨어짐
    • 서비스의 ip를 통해서 접근하면 파드에 항상 연결 가능
  • Service Type의 Default 설정
  • 서비스에 여러 파드를 연결하면 서비스가 트래픽 분산을 해줌
  • 외부 접근 불가, 클러스터 내에서만 접근 가능
  • 운영자, 내부 대시보드 용도
• NodePort
  • 모든 노드에 같은 서비스 포트가 할당 (port: 30000~32767)
  • 외부에서 해당 노드의 포트로 접속시 서비스에 연결 > 서비스에 연결되어 있는 파드의 트래픽을 전달
  • 내부망 연결, 데모나 임시 연결 용도
• LoadBalancer
  • 로드밸런스가 생성되어 각각의 노드로 트래픽 분산 (별도의 플러그인 설치 필요)
  • 외부 시스템 노출 용도

 

Volume

• emptyDir
  • pod안에서 컨테이너들의 데이터를 저장, 파드 삭제시 볼륨 없어짐
• hostPath
  • 각 노드의 path를 볼륨으로 사용, 파드들이 노드 볼륨을 공유하기 때문에 파드가 삭제돼도 볼륨 유지
  • 파드가 재생성될 때 다른 노드에 생기면 문제
  • 파드 자신이 할당되어 있는 노드에서 데이터를 읽거나 쓸 경우 사용
  • 파드 생성 전 노드에 해당 경로가 있어야 함
• PVC/PV
  • User(서비스담당자), Admin(운영자) 영역을 나누고
  • Admin은 각각의 pv(nfs,git..) 정의
  • User는 pv를 사용하기 위해 pvc를 생성
  • k8s가 pvc에 적합한 pv를 연결 해줌
  • 파드 생성시 pvc를 사용
• Dynamic Provisioning
  • StorageClass와 프로비저너를 사용하여 자동으로 PV를 생성해서 PVC와 Bound 시키는 기능

 

ConfigMap, Secret

• 컨테이너 환경에 따라 변경되는 설정 값들을 외부에서 관리
• secret의 value는 Base64로 인코딩해서 값을 넣어야 함
• 사용 방법
  • Env (Literal) - 설정에 상수 값을 정의
  • Env (File) - 설정에 File을 매핑, 파일 내용이 변경되면 파드에 반영되지 않음
  • Volume Mount (File) - 설정에 마운트 정보 등록, 파일 내용이 변경되면 파드에 반영됨
  • 적용 후 확인은 컨테이너 접속 후 env 명령어 실행

 

Ingress

• 여러 서비스간에 트래픽을 분산할 수 있고, 도메인 또는 경로 기반으로 특정 서비스로 트래픽을 라우팅
• L4/L7의 역할을 Ingress가 대신 해줌
• Ingress를 사용하면 Service LoadBalancer 와 Canary Upgrade 가능
• Ingress Controller (NGINX, Kong) 플러그인 설치가 필요
  
  

Controller

Replication Controller(Deprecated), ReplicaSet

• 클러스터 내에서 지정된 복제 수의 파드를 항상 실행되도록 관리하는 역할
• Template
  • 컨트롤러를 생성할 때 템플릿으로 파드의 내용을 정의
  • 파드가 다운되면 템플릿으로 재생성
• Replicas
  • replicas 값 만큼 파드 수를 관리
• Selector 
  • Replication Controller의 selector는 키와 라벨이 같은 파드들만 연결을 해줌
  • ReplicaSet의 selector
    • matchLabels - Replication Controller의 selector와 같은 기능
    • matchExpressions - 밸류를 다양한 조건으로 파드들을 연결 가능

 

Deployment

• 애플리케이션의 배포와 업데이트를 deployment로 쉽게 가능
• 업데이트 방안
  • ReCreate
    • 업데이트시 deployment는 파드를 삭제하기 때문에 서비스 다운 타임이 발생
  • Rolling Update (default)
    • 업데이트시 deployment는 1대의 추가 파드를 생성하고 이전 버전의 파드를 삭제하는 방식
    • 추가적인 자원은 필요하지만 서비스 다운 타임이 없음
  • Blue/Green
    • deployment 기능은 아니고 기존 컨트롤러와 같은 방식으로 새 버전의 컨트롤러를 구성 후 셀렉터의 라벨만 변경하여 버전 업그레이드
    • 자원 사용량이 기존 2배, 서비스 다운 타임이 없음
  • Canary
    • 인그레스 컨트롤러로 유입되는 트래픽을 URL 경로로 구분하여 서비스에 연결을 해주는 역할

 

SatefulSet

• Stateless Application 
  • 배포된 여러 앱이 모두 동일 역할을 수행
  • Web Server (Apache, NGINX, IIS)
  • ReplicatSet (Controller)
    • 공용 볼륨 사용 가능
• Stateful Application
  • 각각의 앱마다 자신의 역할이 있음 (mongoDB - Primary, Secondary, Arbiter)
  • Database (mongoDB, MariaDB, redis)
  • StatefulSet (Controller)
    • 파드마다 역할이 다르기에 개별 볼륨으로 구성

 

Autoscaler

• HPA (Horizontal Pod Autoscaler)
  • 파드의 개수를 증가해주는 설정
  • HPA를 생성하고 컨트롤러에 연결 > HPA는 리소스 상태를 감시 > 위험 상태 감지 > 컨트롤러의 reaplicas 수를 증가 > 컨트롤러는 파드를 추가 생성 (스케일 아웃)
  • 기동이 빠르게 되는 App, Stateless App에서 사용 권장
• VPA (Vertical Pod Autoscaler)
  • 파드의 리소스를 증가해주는 설정
  • VPA를 생성하고 컨트롤러에 연결 > VPA는 리소스 상태를 감시 > VPA가 위험 상태를 감지 > 파드를 재기동하면서 리소스를 스케일 업
  • Statelful App에서 사용 권장
  • 한 컨트롤러에서 VPA, HPA를 함께 사용 불가
• CA (Cluster Autoscaler)
  • 노드를 추가해주는 설정
  • 워커 노드에 자원 모두 소진 > 스케줄러는 CA에게 노드 생성을 요청 > 사전에 CA를 특정 클라우드 프로바이더(GCP, AWS, Azure)와 연결했다면 > 프로바이더의 노드를 생성하고 스케줄러는 해당 노드에 파드를 배치
    
    

Pod

Lifecycle

🔗 참고 URL

 

ReadnessProbe, LivenessProbe

•  ReadnessProbe
  • 파드가 재생성 되면서, 컨테이너의 App이 정상적으로 구동이 완료되어야 파드 연결을 허용
  • Exec (commnad) 옵션으로 파일 존재 여부를 체크
• LivenessProbe
  • 파드를 생성할 때 LivenessProbe 옵션을 적용하면, 컨테이너의 App의 장애 상태를 감시하고 문제 발생시 파드를 재기동하여 지속적 에러 상태를 방지
  • httpGet으로 response status가 200이 아닐 경우 파드를 재기동

 

QoS Classes (Quality of Service)

• k8s에서는 자원이 부족할 경우 App에 중요도에 따라 파드를 다운시켜 자원을 확보
• Qos는 containers의 resources(request,limit) 속성으로 파드 우선 순위가 결정 됨
  • 우선순위: Guaranteed > Burstable > BestEffort
• Guaranteed
  • 파드에 여러 컨테이너가 있다면, 이 컨테이너에 request, limit 설정이 있어야 함
  • request, limit에는 mem,cpu 모두 설정되어 있어야 함
  • 각 컨테이너에 mem,cpu의 request, limit의 값이 같아야 함
• Burstable
  • 컨테이너에 request,limit 설정이 존재하는 경우 
• BestEffort
  • 파드에 어떤 컨테이너 내에도 request, limit 설정이 없어야 함

 

Node Scheduling

• 스케줄러는 아래의 파드 설정들로 다양한 조건의 파드 배치가 가능
•  NodeName
  • 스케줄러와는 상관 없이 파드에 지정한 노드로만 할당
  • 노드 네임이 변경될 수 있기 때문에 실제로 사용하지 않는 설정
• NodeSelector
  • 파드에 key-value 라벨을 정의하여, 라벨과 일치하는 노드에 할당
  • key-value가 매칭이 되어야만 노드에 할당, 매칭되는 라벨이 없으면 파드는 노드 할당이 되지 않아 에러 발생
• NodeAffinity
  • 파드에 key만 설정해도 스케줄러가 해당 key가 일치하는 (자원이 많은) 노드로 할당
  • 조건에 맞지 않는 key를 가지고 있더라도, 스케줄러가 판단하여 (자원이 많은) 노드로 할당
• Pod Affinity
  • web, server 파드가 hostpath에 pv를 사용할 때, 파드들을 같은 노드로 할당 시키는 경우에 사용
• Pod Anti-Affinity
  • master, slave 구조로 같은 노드에 파드가 할당되면 안되는 경우에 사용
• Toleration / Taint
  
  • GPU 노드에 Taint를 설정하면 Toleration이 있는 파드만 해당 노드에 할당 됨