컨테이너 인프라 환경

크게 컨테이너, 컨테이너 관리, 개발환경 구성 및 배포 자동화, 모니터링으로 구성

Provision [IaC] : Terraform을 주로 사용, 그 외에도 Heat(Openstack), Cloudformation(AWS) 등이 있다.

1. 컨테이너
   • Docker
2. 컨테이너 관리
   • Docker Swarm mode → 컨테이너 런타임으로 docker만 사용 할 수 있어서 k8s를 많이 사용docker only)
   • K8S → docker 외에도 오케스트레이션 도구로 사용 가능
3. 개발환경 구성 및 배포 자동화
   • Jenkins → CI/CD 지원
   • Jenkins와 Github Action/Git lab/Git hb 등을 함께 사용한다.
   • 그 외에도 뱀부, 팀시티 등도 있지만 Jenkins가 가장 대표적이다.
4. 모니터링
   • 프로메테우스 + 그라파냐 → 프로메테우스 : 데이터 수집, 그라파냐 : 시각화, 컨테이너로 패키징 돼 동작
   • 데이터 수집 도구 : 프로메테우스 외에도 데이터독, 인플럭스DB, 뉴 델릭 등이 있지만 오픈소스를 활용하는 기업에서는 프로메테우스가 탁월한 효율
   • 시각화 도구 : 그라파냐 외에도 키바나, 크로노그래프 등이 있는데 주로 그라파냐, 키바나 사용. 그러나 프로메테우스와 간결한 구성은 그라파냐 선호

Kubernetes

K8S → 서비스 : Pod 단위 : 한 개 이상의 컨테이너의 집합

helm(헬름)은 k8s 환경에서 포드, 서비스, 컨피그맵, 시크릿, PV/PVC 등을 하나하나 설치하는 방법이 아닌 일종의 패키지 형식으로 간단히 설치하는 방법을 제공한다.

마치 CentOS에서 패키지를 손쉽게 dnf 또는 yum을 이용하여 배포하는 것과 비슷한 원리이다.

swarm mode에서는 manager, worker라고 부르지만, k8s에서는 master, worker (또는 node)라고 한다.

legacy data center architecture vs sdn

master, control plain

Kubernetes 구성 방법

1. 완전 관리형 쿠버네티스
   • EKS(Amazon Elastic Kubernetes), AKS(Azure Kubernetes Services), GKE(Google kubernetes Engine)
   • 구성이 이미 갖추어져 있고, 마스터 노드를 클라우드 업체에서 제공해 밑에 OS와 Physical resource에는 접근이 불가능
   • 학습용으로는 적합하지 않음
2. 구성형 쿠버네티스
   • kubeadm, kops, KRIB, kubespray
   • kubeadm을 주로 사용. 온프레미스와 클라우드 모두 지원

p96~

마스터노드

kubectl

• Developer/관리자가 kubectl 로 쿠버네티스 클러스터에 명령을 내림
• 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없지만, API 서버와 주로 통신하므로 이곳에 구성

API 서버

• 클러스터 중심 역할하는 통로
• 주로 상태 값 지정하는 etcd와 통신, 그 외에도 API 서버를 중심을 두고 통신

etcd

• 분산코디네이터
• 구성요소들의 상태값이 모두 저장되는 곳
• 분산 저장이 가능한 key-value 저장소

스케쥴러

• 노드의 상태, 자원, 레이블, 요구 조건등을 고려해 pod를 어떤 워커 노드에 생성할 것인지 결정하고 할당

컨트롤러 매니저

• 쿠버네티스 클러스터의 오브제그 상태 관리
• 워커 노드에서 통신이 안될 때, 상태 체크 및 복구는 노드 컨트롤러에서 이루어짐
• 레플리카셋 컨트롤러는 레플리카셋에 요청받은 파드 개수대로 파드 생성

워커노드

kubelet

• pod의 구성 내용(podspec)을 받아 컨테이너 런타임으로 전달하고, 파드 안 컨테이너들의 작동 모니터링

컨테이너 런타임(CRI)

• pod를 이루는 컨테이너의 실행 담당
• 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스

kubelet으로 통신할 때 표준인터페이스 CRI (docker 데몬을 빼고 containerd로)에 맞추어 통신

Pod(포드,파드)

• 한 개 이상의 컨테이너의 조합
• 애플리케이션 배포의 최소 단위
• 일반적으로 한개의 주 컨테이너와 다른 한개의 보조 컨테이너로 연결
• 보조 컨테이너 : side-car라고 부르며 주로 주 컨테이너를 모니터링 하거나 로그 수집 등에 활용
• 포드 내의 컨테이너는 별도의 노드로 분리되지 않는다.
• 언제라도 죽을 수 있는 존재

선택 가능한 구성 요소

네트워크 플러그인

• 외부 플러그인
• 주로 캘리코, 로마나 등 이용
• 여기서는 캘리코 선택

CoreDNS

• 각 포드별로 이름을 부여하고 해당 이름에 대한 IP 정보를 매핑하여 보관한다
• 따라서 포드 간 통신시 각 포드의 IP 정보를 확인할 필요 없이 이름으로 접속할 수 있게 된다

k8s에서는 모든 오브젝트(Pod, Replicaset, Deployment, service, configmaps/secret, ingress, pv, pvc…)는 yml 파일 형태로 작성하여 배포가 가능하다. 이를 “매니페스트 파일” 이라 한다.

물론 명령을 통해서도 배포는 가능하다. 하지만 재사용 등을 고려했을 때 파일 작성을 추천한다.

v1.18 → v1.25

• v1.24에서 runtime에 docker(dockerd 도커 데몬)가 빠지게 되어 docker image ls 같은 명령어를 수행할 수 없음
• containerd를 이용해 별도의 명령어를 사용해서 아직까지는 회사에서 이 버전을 쓰지는 않는 편

Container vs Pod

Container(런타임)

• 1컨테이너 → 1애플리케이션 이므로 배포한다고 말함(가상머신은 프로비저닝)
• 1namespace - 1컨테이너

Pod(k8s)

• 1개이상 컨테너가 그룹으로 묶임 →
• 1Pod에 1개의 namespace (컨테이너별로 namespace가 적용되지않음)
• pod별로 CPU, RAM,NIC을 공유해서 사용하는 것, IP는 공유되기 때문에 각 컨테이너는 포트를 지정해서 들어가야 한다.

오브젝트

• k8s는 모든 기능들을 오브젝트(객체)로 관리한다.

기본 오브젝트

1. Pod

   • 쿠버네티스에서 실행되는 최소 단위
   • 독립적인 공간과 사용 가능한 IP 가짐
   • 하나의 pod는 하나 이상의 컨테이너를 가짐

2. 네임스페이스

   • -n으로 사용자별로 namespace를 구분할 수 있다.
   • 공유되는 namespace → persistent volume namespace
   • 여기서는 기존 알고있던 네임스페이스와는 다른, 오브젝트에서의 네임스페이스이다

3. 볼륨

   • pod가 생성될 때 pod에서 사용할 수 있는 디렉터리 제공
   • 기본적으로 pod는 영속되는 개념이 아니라 제공되는 디렉터리 임시 사용
   • pod 사라져도 저장 보존 가능한 디렉토리를 볼륨 오브젝트를 통해 생성 사용 가능

4. 서비스

   • 오브젝트에서 말하는 서비스란 웹서비스같은 것이 아니라 pod를 외부에 노출시키고 외부에서 연결이 가능하도록 하기 위한 오브젝트로써 다음과 같은 세가지를 이용한다.
   1. cluster ip
      • 두개의 포드가 있는 경우 각 포드별로 별도의 IP 주소를 사용한다. 이들은 서로 간 통신을 할 경우 각 포드가 서로 다른 노드에 있다고 가정한다면 이들을 마치 하나의 네트워크에 연결하기위한 환경이 필요한데 이러한 클러스터 상에서 서로 다른 노드에 있는 포드들간 통신이 가능하도록 하기 위하여 cluster ip를 두게 된다.
      • 노드(가상머신) 밖으로 노출은 안되고, 클러스터 상에서 통신할 때만 사용
   2. node port : 서비스의 특정 포트와 pod를 연결하여 외부로부터 연결 가능
   3. load balancer : 로드밸런서를 이용하여 pod와 연결(L4처럼)

   L7 로드밸런서와 같은 기능은 ingress 오브젝트에서 제공된다.(이것은 서비스 오브젝트는 아님)

디플로이먼트

• 기본 오브젝트만으로도 쿠버네티스를 사용할 수 있지만, 효율적으로 작동하도록 기능을 조합하고 추가해 구현
• 이외에도 데몬셋, 레플리카셋, PV(PersistentVolume), PVC(PersistentVolumeClaim) 등이 있다.
  • 데몬셋 : 각 노드에 무조건 일괄적으로 하나씩 배포. 모니터링 등에 활용하면 유용
  • 컨피그맵(configMap) : 시스템 환경변수, 일반적인 파일 등을 제공하기 위한 방법
  • Secret : 컨피그맵과 거의 동일하지만 해당 데이터가 외부에 노출되지 않는다는 장점이 있어서 주로 인증서, username/password, ssh 접속 등과 같은 보안성을 요구하는 곳에서 활용한다. 가령, 특정 사설 저장소로 접속하기 위한 username, password, address를 secret으로 작성하여 yaml파일에 적용할 경우 특정 저장소에서 파일을 다운로드할 때 유용하다.
  • 레플리카셋 : 파드를 여러개 생성가능. 그러나 파드 수를 보장하는 기능만 제공하기 때문에 디플로이먼트로(롤링 업데이트 기능이 추가된) 관리하기를 권장

PV, PVC