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

 

컨테이너 인프라 환경 이란 리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경을 말한다.

 

컨테이너는 하나 이상의 목적을 위해 독립적으로 작동하는 프로세스이다.

3.1 쿠버네티스 이해하기

실제로 쿠버네티스는 컨테이너 오케스트레이션을 위한 솔루션이다.

 

오케스트레이션(Orchestration)이란 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공하는 것을 의미한다. 다수의 컴테이너를 유기적으로 연결, 실행, 종료할 뿐만 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어 주는 것이다.

 

컨테이너 오케스트레이션을 제공하는 솔루션들이 있다.

• 도커 스웜
• 메소스
• 노매드
• 쿠버네티스

3.1.2 쿠버네티스 구성방법

1. 퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스
2. Rancher, 레드햇의 OpenShift와 같은 플랫폼에서 제공하는 설치형 쿠버네티스(유로)
3. 사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성해주는 솔루션

 

 

 

※ 설치 과정은 생략하겠습니다. ※ 

 

 

 

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

kubectl, kubelet, API, 서버, 캘리코 등 모두 쿠버네티스 클러스터를 이루는 구성 요소이다.

그 외에도 etcd, 컨트롤러 매니저, 스케줄러, kube-proxy, 컨테이너 런타임, 파드 등이 있다.

 

kubectl get pods --all-namespaces

 

중복되는 이름을 피하기 위해 뒤에 해시 코드가 삽입되는데 이 때, 해시코드는 무작위 문자열로 생성

 

마스터 노드

1. kubectl
   • 쿠버네티스 클러스터에 명령을 내리는 역할.
   • 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없지만, 통상적으로 API 서버와 주로 통신하므로 책에서는 마스터 노드에 구성
2. API 서버
   • 쿠버네티스 클러스터의 중심 역할을 하는 통로
   • 주로 상태 값을 저장하는 etc와 통신
   • 그 밖의 요소들 또한 API 서버를 중심에 두고 통신하므로 API 서버의 역할이 중요하다.
3. etcd
   • 구성 요소들의 상태 값이 모두 저장되는 곳이다.
   • etcd의 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구될 수 있다.
4. 컨트롤러 매니저
   • 컨트롤러 매니저는 쿠버네티스의 클러스터의 오브젝트 상태를 관리한다.
   • 예를 들어 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다.
5. 스케줄러
   • 노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지 결정하고 할당.
   • 스케줄러라는 이름에 걸맞게 파드를 조건에 맞는 워커 노드에 저장하고, 파드가 워커 노드에 할당되는 일정을 관리하는 역할을 담당한다.

워커 노드

1. kubelet
   • 파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링한다.
2. 컨테이너 런타임(CRI)
   • 파드를 이루는 컨테이너의 실행을 담당한다.
   • 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스이다.
3. 파드
   • 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서모인 단위이다.
   • 즉 웹 서버 역할을 할 수도 있고 로그나 데이터를 분석할 수도 있다.
   • 중요한 점은 파드는 언제라도 죽을 수 있는 존재이다.
     • 가상 머신은 언제라도 죽을 수 있다고 가정하고 디자인 하지 않는다.
     • 파드는 언제라도 죽을 수 있다고 가정하고 설계됐기 때문에 여러 대안을 디자인했다.

선택 가능한 구성 요소

1. 네트워크 플러그인
   • 쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성해야한다.
   • 네트워크 플러그인은 일반적으로 CNI(Container Network Interface)로 구성한다.
2. CoreDNS
   • 클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트로, 빠르고 유연한 DNS 서버이다.
   • 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는데 사용한다.
   • 쿠버네티스 클러스터를 구성하여 사용할 때는 IP보다 도메인 네임을 편리하게 관리해주는 CoreDNS 를 사용하는 것이 일반적이다.

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

1. kube-proxy
   • 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정한다.
   • 실제 통신은 br_netfilter와 iptables로 관리한다.
2. 파드
   • 이미 배포된 파드에 적속하고 필요한 내용을 전달받는다.
   • 사용자는 파드가 어느 워커 노드에 위치하는지 신경 쓰지 않아도 된다.

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

• 쿠버네티스는 작업을 순서대로 진행하는 워크플로 구조가 아니라 선언적인 시스템 구조를 가지고 있다.
• 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다는 뜻이다.

=> 추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 와서 현재 상태와 비교하고 그에 맞게 상태를 변경하려고 한다.

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

 

kubectl

kubectl은 꼭 마스터 노드에 위치할 필요가 없다. 쿠버네티스 클러스터의 외부에서 쿠버네티스 클러스터 명령을 내릴 수도 있다.
=> kubectl이 어디에 있더라도 API 서버의 접속 정보만 있다면 어느 곳에서든 쿠버네티스 클러스터에 명령을 내릴 수 있다.

명령을 실행해도 노드들에 대한 정보가 표시되지 않는다.

 

kubectl get nodes 명령에 추가로 쿠버네티스 클러스터 정보를 입력받는 옵션(--kubeconfig)과 마스터 노드에 받아온 admin.conf를 입력하고 실행한다.

노드 정보가 정상적으로 표시 된다.

 

kubelet

파드의 생성과 상태 관리 및 복구 등을 담당하는 중요한 구성 요소이다.

kubelet에 문제가 생기면 파드가 정상적으로 관리되지 않는다.

 

• kubectl get pod
  • 배포된 파드가 정상적으로 배포된 상태(Running)인지 확인
• kubectl get pods -o wide
  • 명령을 실행해 파드가 배포된 워커 노드를 확인한다.
  • -o는 output의 약어로 출력을 특정 형식으로 해주는 옵션
  • wide는 제공되는 출력 형식 중에서 출력 정보를 더 많이 표시해주는 옵션
• kubectl delete pod nginx-pod
  • nginx-pod를 삭제하는 명령어

 

kube-porxy

파드의 통신을 담당

 

3.2 쿠버네티스 기본 사용법 배우기

3.2.1 파드를 생성하는 방법

쿠버네티스를 사용한다는 것은 결국 사용자에게 효과적으로 파드를 제공하다는 뜻이다.

 

• kubectl create nginx --image=nginx
  • 해당 명령은 에러가 발생한다.

create로 파드를 생성하려면 kubectl create에 deployment를 추가해서 실행해야 한다.

• kubectl create deployment dpy-nginx --image=nginx

두 파드의 nginx 웹 페이지가 정상적으로 작동한다.

 

run과 create, deployment로 파다를 생성하는 것은 무슨 차이가 있을까?

• run은 파다를 생성하면 단일 파드 1개만 생성되고 관리
  => 초코파이 1개
• create deployment로 파드를 생성하면 디플로이먼트라는 관리 그룹 내에서 파드가 생성된다.
  => 초코파이 상자에 들어있는 초코파이 1개

3.2.2 오브젝트

쿠버네티스를 사용하는 관점에서 파드와 디플로이먼트는 스펙과 상태 등의 값을 가지고 있다.

이러한 값을 가지고 있는 파드와 디플로이먼트를 개별 속성을 포함해 부르는 단위를 오브젝트라고 부른다.

 

기본 오브젝트

• 파드
  • 쿠버네티스에서 실행되는 최소 단위
  • 독립적인 공간과 사용 가능한 IP를 가지고 있다.
  • 하나의 파드는 1개 이상의 컨테이너를 갖고 있기 때문에 여러 기능을 묶어 하나의 목적으로 사용할 수도 있다.
    => 일반적으로 1개의 파드에 1개의 컨테이너를 적용한다.
• 네임스페이스
  • 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹
  • 특별히 지정하지 않으면 기본으로 할당 되는 default
  • 쿠버네티스 시스템에서 사용되는 kube-system
  • 온프레미스에서 쿠버네티스를 사용할 경우 외부에서 쿠버네티스 클러스터로 접속하게 도와주는 컨테이너들이 속해 있는 metallb-system
• 볼륨
  • 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공
  • 파드는 영속되는 개념이 아니라 제공되는 디렉터리도 임시로 사용한다.
  • 파드가 사라지더라도 저장과 보존이 가능한 디렉터리를 볼륨 오브젝트를 통해 생성하고 사용할 수 있다.
• 서비스
  • 파드는 클러스터 내에서 유동적이기 때문에 접속 정보가 고정일 수 없다.
    => 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결된다.
  • 새로 파드가 생성될 때 부여되는 새로운 IP를 기존에 제공하던 기능과 연결해준다.
    => 외부에서 쿠버네티스 내부로 접속할 때 내부가 어떤 구조로 돼 있는지, 파드가 살았는지 죽었는지 신경 쓰지 않아도 이를 논리적으로 연결하는 것.
    => 로드밸런서, 게이트웨이와 비슷한 역할을 한다.

디플로이먼트

기본 오브젝트만으로도 쿠버네티스를 사용할 수 있다. 좀 더 효율적으로 작동하도록 기능들을 조합하고 추가해 구현한 것이 디플로이먼트이다.

=> 그 외 레플리카셋, 데몬셋, 컨피그맵, PV, PVC 등이 있다.

 

쿠버네티스에서 가장 많이 쓰이는 디플로이먼트 오브젝트는 파드에 기반을 두고 있으며, 레플리카셋 오브젝트를 합쳐 놓은 형태이다.

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

 

 

 

---

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

쿠버네티스에서는 외부에서 쿠버네티스 클러스터에 접속하는 방법을 서비스라고 한다.

서비스를 '소비를 위한 도움을 제공한다'는 관점으로 바라본다면 쿠버네티스가 외부에서 쿠버네티스 클러스터에 접속하기 위한 '서비스'를 제공한다고 볼 수 있다.

 

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

외부에서 쿠버네티스 클러스터의 내부에서 접속하는 가장 쉬운 방법은 노드포트(NodePort) 서비스를 이용하는 것이다.

 

1. 노드포트 서비스를 설정하면 모든 워커 노드의 특정 포드를 열고 사용자의 요청을 받는다.
2. 여기로 오는 모든 요청을 다시 노드포트 서비스로 전달한다.
3. 노드포트 서비스는 해당 업무를 처리할 수 있는 파드로 요청을 전달한다.

 

노드포드 서비스로 외부에서 접속하기

1. 디플로이먼트로 파드를 생성하기.
   • kubetctl create deployment np-pods --image=sysnet4admin/echo-hname
2. 배포된 파드를 확인
   • kubectl get pods
3. 노드포트 서비스를 생성
   • kubectl create -f ~/중간생략/nodepart.yaml

 

 

부하 분산 테스트하기

 

 

 

 

expose로 노드포트 서비스 생성하기

1. 서비스로 내보낼 디플로이먼트를 np-pods로 지정
   → expose를 사용하면 노드포트의 포트 번호를 지정할 수 없고 30000 ~ 32767에서 임의로 지정됨.
   
   • kubectl expose deployment np-pods --type=NodePort --name=np-svc-v2 --port=80
2. 생성된 서비스 확인
   • kubcetl get services

 

 

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

노드포트 서비스는 포트를 중복으로 사용할 수 없어서 1개의 노드포트에 1개의 디플로이먼트만 적용한다.

여러 개의 디플로이먼트가 있을 때 그 수만큼 노드포트 서비스를 구동해야할까?

→ 쿠버네티스에서는 인그레스(Ingress)를 사용한다.

 

인그레스는 고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공한다.

 

인그레스를 사용하려면 인그레스 컨트롤러가 필요하다.

다양한 인그레스 컨트롤러가 있지만, NGINX 인드레스 컨트롤러로 구성한다.

 

1. 사용자는 노드마다 설정된 노드포트를 통해 노드포트 서비스로 접속한다. 노트포트 서비스를 NGINX 인그레스 컨트롤러로 구성한다.
2. NGINX 인그레스 컨트롤러는 사용자의 접속 경로에 따라 적합한 클러스터 IP 서비스로 경로를 제공한다.
3. 클러스터 IP 서비스는 사용자를 해당 파트로 연결해준다.

 

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

 

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

MetalLB는 베어메탈(bare metal, 운영 체제가 설치 되지 않은 하드웨어)로 구성된 쿠버네티스에서도 로드밸런서를 사용할 수 있게 고안된 프로젝트이다.

MetalLB는 특별한 네트워크 설정이나 구성이 있는 것이 아니라 기존의 L2 네트워크(ARP/NDP)와 L3 네트워크(BGP)로 로드밸런서를 구현한다.

 

 

 

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

 

 

---

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

이전 장까지 파드를 안정적으로 사용하는 방법을 배우며 파드를 관리하는 여러 가지 기능이 포함된 디플로이먼트 오브젝트를 사용했다.

디플로이먼트 외에도 용도에 따라 사용할 수 있는 다양한 오브젝트가 이미 정의 돼있다.

3.4.1  데몬셋

데몬셋은 디플로이먼트의 replicas가 노드 수만큼 정해져 있는 형태라고 할 수 있는데, 노드 하나당 파드 한개만을 생성한다.

노드의 단일 접속 지점으로 노드 외부와 통신하는 것이다.

따라서 파드가 1개 이상 필요하지 않다.

 

3.4.2 컨피그맵

컨피그맵(ConfigMap)은 이름 그대로 설정(config)을 목적으로 사용하는 오브젝트이다.

 MetalLB을 구성할 대 컨피그맵을 사용했다.