02. 기본 개념

Kubernetes 등장 배경 §

배포 환경의 변천사 §

출처: https://kubernetes.io/docs/concepts/overview/

• 기존의 배포환경: 물리 서버 한대에 여러 App 들을 설치하여 배포하였다.
  • 한계점: 각 App 들을 격리시키지 못해 하나의 App 이 너무나 많은 리소스를 점유하는 등의 문제가 발생한다.
• 가상화 배포환경: 물리서버 한대에 여러 가상머신 (Virtual Machine, VM) 을 생성해 각 App 들을 격리시켰다.
  • 한계점: 가상머신은 가상화를 위한 Hypervisor 가 필요하고 가상머신 내에도 OS 가 설치되기에 다소 무겁고 리소스 사용량이 많다는 문제가 있다.
• 컨테이너 배포환경: 물리서버 한대에 여러 컨테이너를 생성해 각 App 들을 격리시켰다.
  • 컨테이너는 호스트 머신과 커널을 공유하기 때문에, 추가적인 OS 가 필요 없어 가상화 배포환경보다 가벼운 격리 배포환경을 구축할 수 있다.

Kubernetes 배포 환경 §

• Kubernetes 에서는 이러한 컨테이너 배포환경에 더 높은 추상화를 제공해 컨테이너 형태의 App 들을 훨씬 쉽고 효율적으로 관리할 수 있게 해준다.

Kubernetes 구성요소 §

출처: https://kubernetes.io/docs/concepts/overview/components/

• API Server
  • 클러스터를 관리하는 ReST API 를 제공하는 컨테이너이다.
• Cloud-controller manager
  • 쿠버네티스가 클라우드 상에서 작동한다면, 해당 클라우드 프로바이더의 API 와 연동하여 클라우드의 리소스를 제어하는 컨테이너이다.
    • EKS 를 예시로 들자면, 쿠버네티스에 LB type service 가 생성되면 AWS ALB 를 자동으로 생성 & 설정해주는 등
  • 클라우드상에서 작동하지 않는다면, 설치하지 않아도 되는 구성요소이다.
• Controller manager
  • 생성된 리소스가 바람직한 상태를 유지하도록 하는 컨테이너이다.
• ETCD
  • 클러스터의 모든 정보가 저장되는 키-벨류 기반의 데이터베이스 컨테이너이다.
  • 클러스터의 모든 정보가 저장되기에, ETCD 의 데이터가 깨지게 되면 클러스터 전체가 망가지게 된다.
• Kubelet
  • 쿠버네티스 클러스터를 구성하는 물리 머신에 설치되는 시스템 데몬(Systemd service)으로, API Server 와 컨테이너 런타임과 통신하며 컨테이너들을 관리한다.
• Kube-proxy
  • 노드 내외부의 통신을 담당하는 컨테이너이다.
• Scheduler
  • 새로운 파드가 생성되었을때, 해당 파드를 어느 노드에 실행시킬지 선택하는 컨테이너이다.

Kubernetes 의 기본적인 작동 원리 §

“상태” §

• 바람직한 상태: 사용자가 kubectl 등을 통해 지정해준 사용자가 원하는 리소스의 형태
• 현재 상태: 실제 쿠버네티스 클러스터에의 리소스의 형태
• 상태를 일치시키기 위해 노력하는 것: 컨트롤러
• 이렇게 사용자는 원하는 상태를 클러스터에 알려주는 형식으로 리소스를 생성한다 → 선언적 (Declarative) 아키텍처

Spec, Status §

• 바람직한 상태와 현재 상태는 모두 리소스의 YAML 에 저장된다.
  • 바람직한 상태는 spec 에 명시
  • 현재 상태는 status 에 명시
• kubectl get deployment ... -o yaml 로 spec 과 status 를 확인해보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2023-01-25T06:17:49Z"
  generation: 1
  labels:
    app: nginx
  name: nginx
  namespace: default
  resourceVersion: "66785"
  uid: e6fbe72b-9198-4928-8ead-0cd515449835
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:stable
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2023-01-25T06:17:50Z"
    lastUpdateTime: "2023-01-25T06:17:50Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2023-01-25T06:17:49Z"
    lastUpdateTime: "2023-01-25T06:17:50Z"
    message: ReplicaSet "nginx-76769d88f7" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1