3장 - 컨테이너를 다루는 표준 아키텍처, 쿠버네티스

• 여기서 컨테이너는 하나 이상의 목적을 위하 독립적으로 작동하는 프로세스 입니다.
• 컨테이너 인프라 환경을 구성하면 눈송이 서버를 방지하는데 효과적 임

  • 눈송이 서버 = 여러 사람이 만져서 설정의 일관성이 떨어진 서버
• 가상화 환경에서는 각각의 가상머신이 모두 독립적인 운영 체제 커널을 가지고 있어야 하기 때문에 그만큼 자원을 더 소모해야 하고 성능이 떨어질 수밖에 없다.

  • But. 컨테이너 인프라 환경은 운영 체제 커널 하나에 컨테이너 여러 개가 격리된 형태로 실행 때문에 자원의 효율적 사용, 거치는 단계가 적어 속도도 훨씬 빠름!

• 이를 통해 쿠버네티스를 누구나 자유롭게 이용하게 되면서 컨테이너 인프라 환경을 좀 더 효율적으로 관리할 수 있게 되었음
• 여러 기능이 추가되며 쿠버네티스는 컨테이너 인프라 관리 솔루션의 표준으로 자리잡게 됨

3.1 쿠버네티스 이해하기#

• 오케스트레이션이란? 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공하는 것을 의미합니다.

3.1.1 왜 쿠버네티스일까#

• k8s의 의미

  • 쿠버네티스는 그 이름 자체가 긴 단어이기 때문에 문자 수를 표기하는 방법으로 약어를 만들었습니다.
  • k8(ubernete = 8글자)s

3.1.2 쿠버네티스 구성 방법#

1. 퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스인 EKS, AKS, GKE 등을 사용합니다.

   • 구성이 이미 다 갖춰져 있고 마스터 노드를 클라우드 업체에서 관리하기 때문에 학습용으로는 적합하지 않음
2. 수세의 Rancher, 레드햇의 OpenShift와 같은 플랫폼에서 제공하는 설치형 쿠버네티스를 사용합니다.

   • 유료이기 때문에 쉽게 접근이 어렵다.
3. 사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성해주는 솔루션을 사용한다.

   • kubeadm, kops, KRIB, kubespray가 대표적
   • 위 4가지 솔루션중 kubeadm가 가장 널리 알려져 있다.

     • 사용자 변경이 수월
     • 온프레미스와 클라우드를 모두 지원
     • 배우기도 쉬움

3.1.3 쿠버네티스 구성하기#

• 학습을 위해 사용자 설정이 많이 필요한 kubeadm으로 쿠버네티스를 구성
• 쿠버네티스가 설치되는 서버 노드는 가상 머신을 이용해 실제 온프레미스에 가깝게 구성

3.1.4 파드 배포를 중심으로 쿠버네티스 구성요소 살펴보기#

# kubectl get pods --all-namespaces

• --all-namespaces는 기본 네임스페이스인 default외에 모든 것을 표시하겠다는 의미
• 쿠버네티스 클러스터를 이루는 구성요소들은 파드 형태로 이루어져 있음을 알 수 있음

관리자나 개발자가 파드를 배포할 때#

1. kubectl : 쿠버네티스 클러스터에 명령을 내리는 역할

   • 다른 구성요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없다.
   • 통상적으로 API 서버와 주로 통신
2. API 서버 : 주로 상태 값을 저장하는 etcd와 통신

   • 그 밖의 요소들 또한 API 서버를 중심으로 통신

     • 때문에 API 서버의 역할이 매우 중요
3. etcd : 구성 요소들의 상태 값이 모두 저장되는 곳

   • 회사의 관리자가 모든 보고 내용을 기록하는 노트라고 생각하면 됨
   • 실제로 etcd외 다른 구성요소는 상태 값을 관리하지 않는다.
   • 때문에 etcd의 정보만 백업돼 있다면 긴습한 장애 상황에서도 쿠버네티스 클러스터를 복구할 수 있음
   • 또한 etcd는 분산 저장이 가능한 key-value 저장소로서 복제해 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나도 시스템 가용성을 확보할 수 있음
   • etcd(엣시디)는 리눅스 구성 정보를 주로 가지는 etc 디렉터리와 distributed(퍼뜨렸다)의 합성어 = 구성 정보를 퍼뜨려 저장하겠다는 의미
4. 컨트롤러 매니저 : 쿠버네티스 클러스터의 오브젝트 상태를 관리

   • 워커 노드에서 통신이 되지 않는 경우. 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어짐
   • 서비스와 파드를 연결하는 역할을 하는 엔드 포인트 컨트롤러 또한 컨트롤러 매니저임
   • 이와 같이 다양한 상태 값을 관리하는 주체들이 컨트롤러 매니저에 소속돼 각자의 역할을 수행
5. 스케줄러 : 노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 어떤 워커 노드에 파드를 생성할 것인지 결정하고 할당하는 역할

   • 이름에 걸맞게 파드를 조건에 맞는 워커 노드에 지정하고, 파드가 워커 노드에 할당되는 일정을 관리하는 역할을 담당
6. kubelet : 파드의 구성 내용(PodSpec)을 받아 컨테이너 런타임에 전달, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링 함
7. 컨테이너 런타임 : 파드를 이루는 컨테이너 실행을 담당

   • 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스
8. 파드(Pod) : 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해 모인 단위

   • 파드는 언제라도 죽을 수 있는 존재

     • 쿠버네티스를 처음 배울 때 가장 이해하기 어려운 부분
     • 가상 머신은 언제라도 죽을 수 있다고 가정하고 디자인하지 않지만, 파드는 언제라도 죽을 수 있다고 가정하고 설계되었음
     • 때문에 쿠버네티스는 여러 대안을 디자인했음

1. 네트워크 플러그인 : 쿠버네티스 클러스터의 통신을 위해 네트워크 플러그인을 선택하고 구성할 수 있음

   • 네트워크 플러그인은 일반적으로 CNI로 구성
   • CNI(Container Network Interface, 컨테이너 네트워크 인터페이스)

     • 클라우드 네이티브 컴퓨팅 재단의 프로젝트
     • 컨테이너의 네트워크 안정성과 확장성을 보장하기 위해 개발 됨
     • 네트워크 프로토콜인 BGP와 VXLAN의 지원, ACL 지원, 보안 기능 제공 등 살펴보고 필요한 조건을 가지고 있는 네트워크 플러그인을 선택할 수 있어 설계 유연성이 매우 높음
2. CoreDNS : 클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트

   • 빠르고 유연한 DNS 서버
   • 클러스터 구성시 IP보다 도메인 네임을 편리하게 관리해주는 CoreDNS를 사용하는게 일반적

사용자가 배포된 파드에 접속할 때#

1. kube-proxy : 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정함

   • 이때 실제 통신은 br_netfilter과 iptables로 관리
2. 파드 : 이미 배포된 파드에 접속하고 필요한 내용을 전달받음

   • 이때 대부분 사용자는 파드가 어느 워커노드에 위치하든지 신경 쓰지 않아도 됨

3.1.5 파드의 생명주기로 쿠버네티스 구성 요소 살펴보기#

1. kubectl을 통해 API 서버에 파드 생성을 요청한다.
2. (업데이트가 있을 때마다 매번) API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로 유지한다.
3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지

   1. 컨트롤러 매니저는 파드를 생성
   2. 아직 어떤 워커노드에 파드를 적용할지는 결정되지 않는 상태로 파드를 생성
4. API 서버에 파드가 생성됐다는 정보를 스케줄러가 인지한다.

   1. 스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해 결정하고 해당 워커노드에 파드를 띄우도록 요청한다.
5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해있는지 스케줄러가 kubelet으로 확인한다.
6. kebelet에서 컨테이너 런타임으로 파드 생성을 요청한다.
7. 파드가 생성된다.
8. 파드가 사용 가능한 상태가 된다.

3.1.6 쿠버네티스 구성 요소의 기능 검증하기#

kubectl#

1. 슈퍼푸티 세션 창에서 w3-k8s를 더블클릭해 터미널에 접속
2. kubectl get nodes를 실행
3. 쿠버네티스 클러스터 정보를 마스터노드에서 scp명령으로 w3-k8s의 현재 디렉터리에 받아옴

   1. 이때 접속기록이 없기 때문에 known_hosts로 저장하도록 함
4. kubectl get nodes 명령에 추가로 쿠버네티스 클러스터 정보를 입력받는 옵션(--kubeconfig)과 마스터 노드에서 받아온 admin.conf를 입력하고 실행

kubelet#

1. 기능 검증을 위해서는 실제 파드를 배포해야함

   1. kubectl create -f ~/_Book_k8sInfra/ch3/3.1.6/nginx-pod.yaml명령으로 nginx 파드를 배포
2. kubectl get pod 명령으로 배포된 파드가 정상적으로 작동중(Running)인지 확인
3. kubectl get pods -o wide 명령을 실행해 파드가 배포된 워커 노드를 확인

   1. -o느 output의 약어로 출력을 특정 형식으로 해주는 옵션
   2. wide는 재공되는 출력 형식 중에서 출력 정보를 더 많이 표시해 주는 옵션
4. 배포된 노드에 접속해 systemctl stop kubelet으로 kubelet 서비스를 멈춘다.
5. m-k8s에서 kubectl get pod로 상태를 확인하고, kubectl delete pod nginx-pod로 파드를 삭제
6. 이후 명령어가 Terminating 상태에서 진행되지 않는것을 확인
7. 다시 노드에 접속해 systemctl start kubelet 명령어를 통해서 kubelet을 복구
8. 잠시 후 kubelet get pod 명령어를 통해 파드가 삭제되었는지 확인

kebe-proxy#

1. 테스트하기 위해 마스터 노드인 m-k8s에서 다시 파드를 배포합니다.
2. kubectl get pod -o wide 명령으로 파드의 IP와 워커 노드를 확인합니다.
3. curl로 파드의 전 단계에서 파드의 전 단계에서 확인한 파드의 IP

3.2 쿠버네티스의 기본 사용법#

kubectl run nginx-pod --image=nginx
kubectl create deployment dpy-nginx --image=nginx

• run = 단일 파드로 생성되고 관리 (초코파이 단일품)
• create deployment = deployment라는 관리 그룹 내세엇 파드가 생성됨 (초코파이 한상자)

오브젝트란#

• 기본 오브젝트

  • 파드 = 쿠버네티스에서 실행되는 최소 단위, 웹 서비스를 구동하는데 필요한 최소 단위
  • 네임스페이스 = 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹
  • 볼륨 = 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공

    • 파드가 사라지더라도 저장과 보존이 가능한 디렉터리 볼륨 오브젝트를 생성/사용 가능
  • 서비스 = 파드는 클러스터 내에서 유동적이기 때문에 접속 정보가 고정일 수 없음

    • 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결됨

• 디플로이먼트

  • 기본 오브젝트만으로도 쿠버네티스를 사용할 수 있지만, 좀 더 효율적인 사용을 위해 구현된것이 바로 디플로이먼트
  • 이 외에도 데몬셋, 컨피그맵, 레플리카셋, PV, PVC, 스테이트풀셋, 등이 있으며 요구사항에 따라 목적에 맞는 오브젝트들이 추가될 것
  • 쿠버네티스에서 가장 많이 쓰이는 디플로이먼트 오브젝트는 파드에 기반을 두고 있다.

    • 레플리카셋 오브젝트를 합쳐 놓은 형태
  • 실제로 API 서버와 컨트롤러 매니저는 단순히 파드가 생성되는 것을 감시하는 것이 아니라 디플로이먼트처럼 레플리카셋을 포함하는 오브젝트의 생성을 감시

3.2.3 레플리카셋으로 파드 수 관리하기#

• 롤링 업데이트 등이 추가된 디플로이먼트를 사용해 파드수를 관리하는것을 권장

3.2.4 스펙을 지정해 오브젝트 생성#

• 야믈문법으로 작성한 오브젝트 스펙을 이용하는 방법

apiVersion: apps/v1 # API 버전
kind: Deployment # 오브젝트 종류
metadata:
  name: echo-hname
  labels:
    app: nginx
spec:
  replicas: 3 # 몇 개의 파드를 생성할지 결정
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: echo-hname
        image: sysnet4admin/echo-hname # 사용되는 이미지

3.2.5 apply로 오브젝트 생성하고 관리하기#

• 오브젝트 생성 명령어 비교

3.2.6 파드의 컨테이너 자동 복구 방법#

3.2.7 파드의 동작 보증 기능#

3.2.8 노드 자원 보호하기#

• 여러 상황 속에서도 쿠버네티스는 파드를 안정적으로 작동하도록 관리 함
• 노드는 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할을 함
• 지속적으로 문제가 생기는 노드의 경우 cordon을 통해서 노드를 관리할 수 있음

3.2.9 노드 유지보수하기#

3.3 쿠버네티스 연결을 담당하는 서비스#

3.3.1 가장 간단하게 연결하는 노드포트#

apiVersion: v1
kind: Service
metadata:
  name: np-svc
spec:
  selector:
    app: np-pods 
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30000 # 30000번의 노드포트를 허용함
  type: NodePort

3.3.2 사용 목적별로 연결하는 인그레스#

• 인그레스 컨트롤러는 파드와 직접 통신할 수 없어서 노드포트 또는 로드밸런서 서비스와 연동되어야 함

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path:
        backend:
          serviceName: hname-svc-default
          servicePort: 80
      - path: /ip
        backend:
          serviceName: ip-svc
          servicePort: 80
      - path: /your-directory
        backend:
          serviceName: your-svc
          servicePort: 80

3.3.3 클라우드에서 쉽게 구성 가능한 로드밸런서#

• 이 방식은 매우 비효율적
• 때문에 쿠버네티스에서는 로그밸런서라는 서비스 타입을 제공해 간단하 구조로 파드를 외부에 노출시키고 부하를 분산

kubectl expose deployment ex-lb --type=LoadBalance --name=ex-svc

3.3.4 온프레미스에서 로드밸런서를 제공하는 MetalLB#

• MetalLB는 베어메탈로 구성된 쿠버네티스에서도 로드밸러서를 사용할 수 있게 고안된 프로젝트
• 특별한 네트워크 설정이나 구성이 있는 것이 아닌 기존의 L2 네트워크와 L3 네트워크로 로드밸런서를 구현함
• 때문에 네트워크를 새로 배워야 할 부담도 적으며 연동하기도 쉬움
• MetalLB의 컨트롤러는 작동 방식을 정의하고 EXTERNAL-IP를 부여해 관리한다.
• MetalLB 스피커는 정해진 작동 방식(L2/ARP, L3/BGP)에 따라 경로를 만들 수 있도록 네트워크 정보를 광고하고 수집해 각 파드의 경로를 제공

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: nginx-ip-range
      protocol: layer2
      addresses:
      - 192.168.1.11-192.168.1.13

3.3.5 부하에 따라 자동으로 파드 수를 조절하는 HPA#

• 이를 HPA(Horizontal Pod Autoscaler)라고 함

• HPA를 통해서 늘어나는 파드 수 계산 방법

  • 디플로이먼트 스펙에서 resources의 CPU를 10m으로 설정하고, autoscale에서 cpu-percent를 50%로 했다고 가정
  • 파드가 29m 라는 부하를 받을 때 한개의 파드가 처리할 수 있는 부하량은 10m으로 CPU 부하량의 50%가 넘으면 자동으로 파드를 생성해야 하기 때문에 5m이 넘으면 파드를 증설
  • 29/5를 한뒤 올림하면 6이라는 숫자가 나오고, 결국 증가하는 파드는6임

3.4 알아두면 쓸모 있는 쿠버네티스 오브젝트#

데몬셋#

컨피그맵#

PV와 PVC#

• 임시: emptyDir
• 로컬: host Path, local
• 원격: persistentVolumeClaim, cephfs, csi, fc 등등
• 특수목적: downwardAPI, configMap, secret 등등
• 클라우드: awsElasticBlockStore, azureDisk

스테이트풀셋#