[k8s] Kubernetes Basics

Udemy의 Rocking Kubernetes with Amazon EKS, Fargate, And DevOps 강의의 Section1 내용과 더불어, 제가 따로 공부한 내용을 정리했습니다.

 

목차

 

1. What is Docker Container?

Python 3.8을 사용하는 Dev 환경에서 프로그램을 개발했다고 가정합시다.

만약 Test에선 Python 3.6을 사용하고, Prod에선 Python 2.7을 사용할 경우, 각 버전의 파이썬은 의존성이 달라서 Dev 환경의 프로그램에 에러가 발생할 것입니다.

이 문제를 추상화를 통해 해결할 수 있습니다.

 

1-1. 추상화란?

추상화는 하드웨어나 운영체제와 같은 세부 사항을 숨기고, 사용자에게 더 단순하고 일관된 인터페이스를 제공하는 것을 의미합니다. 

 

1-2. VM

• VM은 하드웨어 자원 추상화하는 방법입니다.
• 예를 들어 위 예시에서 아래처럼 Dev 환경의 VM, Test 환경의 VM, Prod 환경의 VM을 만들었다고 가정해 봅시다.
• Dev, Test, Prod 환경에서 각 버전의 의존성들을 구성하면 Dev환경의 프로그램을 다른 환경에서 실행해도 의존성 문제가 발생하지 않습니다.

• 단, 위 사진에서 보다시피 각각의 VM은 게스트 OS를 갖고 있습니다.
• 게스트 OS로 인해 각 VM들은 다른 VM의 메모리나 프로세서 등에 접근할 수 없어서 격리성이 강력합니다.
• 하지만 많은 리소스를 사용하므로 크기가 크고 느립니다.

1-3. Container

하드웨어 자원을 추상화하는 VM과 달리, 운영체제를 추상화하는 방법입니다.

• Container들은 하나의 OS를 공유하므로 Guest OS가 필요하지 않아서 리소스를 적게 사용하고, 부팅이 빠릅니다.
• 하지만 VM보다는 격리성이 떨어집니다.
• 단점에 비해 장점이 더욱 뛰어나므로 하드웨어를 추상화하는 방법보다 더 적합합니다.

---

2. What is Container Orchecstrator?

2-1. 컨테이너 오케스트레이터란?

컨테이너 기반의 애플리케이션과 관련한 일들을 처리해주는 도구나 플랫폼입니다.

 

예를 들어, 컨테이너 오케스트레이터는 다음과 같은 일들을 수행합니다.

• 장애 컨테이너 감지 및 복구
• 스케일링
• 로드 밸런싱
• 모니터링

컨테이너 오케스트레이터 종류

• Docker Swarm
• Apache Mesos
• Cattle
• AWS, Elastic Container Service
• Kubernetest (EKS) → most popular

3. Kubernetes Introduction

쿠버네티스 컴포넌트에 대해 알아보겠습니다.

쿠버네티스 구성 요소, 출처: https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 구성 요소는 크게 Control Plane과 Node(Data Plane)으로 나뉩니다.

 

---

3-1. Control Plane Component

컨트롤 플레인은 클러스터에 관한 전반적인 결정을 수행합니다.
해야할 일이 많으므로 컨트롤 플레인은 여러 구성 요소로 나뉩니다.

3-1-1. Etcd

• 일관성과 고가용성을 갖는 key-value 데이터베이스입니다.
• Node, Pod 등 클러스터의 모든 상태 데이터를 저장합니다.

3-1-2. Kube sheduler

• Pod를 적절한 Node에 할당합니다.
• affinity, label, CPU 등을 고려해서 스케줄링합니다.

3-1-3. Kube Controller Manager

다양한 컨트롤러들을 관리하며, 이 컨트롤러들은 desired state와 current state를 일치시키기 위한 작업을 수행합니다.

예를 들어 다음과 같은 컨트롤러들 등이 있습니다.

• Node Controller: 노드의 상태를 모니터링하고 대응합니다.
• Job Controller: 일회성 작업인 Job object를 모니터링하고, 이 작업을 완료할 때까지 동작하는 Pod를 생성합니다.

3-1-4. Kube API server

• 컨트롤 플레인 구성 요소들은 외부에 노출되지 않습니다.
• 따라서 Kube API server가 외부와 통신할 수 있게 합니다.

---

3-2. Data Plane Component (Node Component)

노드 컴포넌트는 동작 중인 Pod를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작합니다.

3-2-1. kubelet

• 클러스터의 각 노드에서 실행되는 에이전트입니다.
• 컨트롤 플레인과 통신해서 Pod에서 컨테이너가 확실하게 동작하도록 관리합니다.
  • Kube API server로부터 받은 PodSpec을 기반으로, Pod를 실행하고 모니터링합니다.
  • Pod의 헬스 체크도 수행합니다.

3-2-2. Kube-proxy

• 클러스터의 각 노드에서 실행되는 네트어크 프록시입니다.
• 네트워크 프록시이며, 노드끼리의 네트워크 규칙을 유지하고 관리합니다.

3-2-3. Container Runtime

• 실제로 컨테이너를 실행하는 소프트웨어입니다.
• 가장 많이 사용되는 것은 Docker와 containerd입니다. 

---

4. Pod

• 컨테이너를 직접적으로 k8s 클러스터에서 실행시킬 수 없습니다.
• 컨테이너는 Pod라고 불리는 쿠버네티스에서 배포 가능한 가장 작은 유닛에서 실행됩니다.
• Pod는 Node에서 실행되며, Node는 쿠버네티스 데이터 플레인이 실행합니다.
• 각 Pod는 고유한 IP 주소를 갖으며, 같은 k8s 클러스터 내 Pod들은 이 IP로 통신할 수 있습니다.
• 하나의 Pod에서 여러 컨테이너를 실행할 수 있습니다.
• 하지만 단순성을 유지하기 위해 주로 하나의 Pod에선 하나의 컨테이너만 실행합니다.

---

5. Replicaset, Deployment

Pod에서 Nginx 1.16을 실행하고 있다고 가정해 봅시다.

replicaset을 사용하면 Pod의 desired 개수를 지정할 수 있으므로 Pod의 가용성을 향상시킵니다.

Deployment는 desired 버전을 지정할 수 있습니다. 따라서 Nginx를 1.16에서 다른 버전으로 변경할 때 사용합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    environment: test
  name: testdeploy
spec:
  replicas: 3
  selector:
    matchLabels:
      environment: test
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        environment: test
    spec:
      containers:
      - image: nginx:1.17
        name: nginx

 

6. Service

위 상황에서 IP가 10.18.32.61인 MySQL Pod가 다운됐다고 가정하겠습니다.

replicaset에 의해 새로운 MySQL Pod가 생성될 것입니다.

Pod는 고유의 IP가 있다고 했으니, 새로 생성된 Pod의 IP는 10.18.32.61과는 다를 것입니다.

그러면 다운된 MySQL과 연결되어 있던 Nginx는 새로 생성된 MySQL Pod를 어떻게 찾을 수 있을까요?

Service가 이 문제를 해결해 줍니다.

Webserver 노드는 Service와 연결하고, Service는 다시 Database 노드와 연결합니다.

그리고 서비스는, IP가 아닌 label을 통해 Pod를 찾고, 그 Pod로 트래픽을 분산시킵니다.

 

7. Service Types

7-1. ClusterIP

• Service 매니페스트에서 유형을 언급하지 않으면 default로 사용되는 유형입니다.
• 클러스터 내에서만 Pod 액세스할 수 있습니다.
• 따라서 프론트엔드가 백엔드가 DB와 통신할 때 유용합니다.

예를 들어 아래 매니페스트 파일을 보겠습니다.

• 서비스는 80번 포트에서 실행되며, label이 app: app-server인 Pod로 트래픽을 분산합니다.
• port는 서비스가 실행되는 포트를 의미하며, targetPort는 트래픽 전달 대상 pod의 포트 번호입니다.
• port와 targetPort가 같을 경우 targetPort를 생략해도 됩니다.
• Deployment의 containerPort는 컨테이너가 접근을 허용하는 포트 번호를 의미합니다.

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: app-server

--

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-server
  labels:
    app: app-server
spec:
  selector:
    matchLabels:
      app: app-server
  template:
    metadata:
      labels:
        app: app-server
    spec:
      containers:
      - name: web-server
        image: nginx
        ports:
        - containerPort: 80

---

7-2. NodePort

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  type: NodePort
  ports:
    - nodePort: 32000
      port: 80
      targetPort: 80
  selector:
    app: app-server

• 노드의 IP 주소를 10.16.10.01이라고 가정하겠습니다.
• 30,000 ~ 32,767 사이의 노드 포트를 선택합니다. ex)32,000
• 그러면 htpps://10.16.10.01:32000을 통해 클러스터 외부에서 pod에 접근할 수 있습니다.
• 노드의 ip를 알아야 하므로 클러스터 외부의 트래픽을 분산할 땐, NodePort보다 LoadBalancer를 많이 사용합니다.

참고:

NodePort는 클러스터의 모든 노드에서 지정된 포트를 개방합니다.

따라서 아래 사진에서 https://10.16.10.01:32000에 접근할 경우, 오른쪽 노드의 ip가 10.18.10.01임에도 오른쪽 노드로도 트래픽이 분산됩니다.

---

7-3. LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

NodePort와 마찬가지로, 외부 트래픽을 Pod로 전달합니다.

클라우드 서비스에서 로드밸런서를 프로비저닝합니다. (AWS의 경우 ELB)

프로비저닝된 밸런서에 대한 정보는 서비스의 .status.loadBalancer 필드에 발행됩니다.

 

---

참고 문서

쿠버네티스 공식 문서: 쿠버네티스 컴포넌트

쿠버네티스 공식 문서: 서비스