1. Container Infra 환경의 Tool
- Container Infra 환경은 크게 컨테이너, 컨테이너 관리, 개발 환경 구성 및 배포 자동화, 모니터링으로 구성된다
-
Provisor 는 IaC 중 하나로, 인프라 환경을 제공해준다. 대표적으로 Terraform, Heat ( openstack ) , CloudFormation ( AWS ) 등이 있다
-
우리는 기존에 도커 스웜 모드를 이용해 애플리케이션을 가볍고 빠르게 배포하였다
- 컨테이너 : 도커 사용
- 오케스트레이션 도구 : 도커 스웜 모드 사용. 허나 이 도커 스웜 모드는 RUNTIME 으로 오직 도커만 사용할 수 있다. 이때, k8s 를 사용하면 다양한 RUNTIME 을 사용할 수 있다
- K8S 는 기존에 Dockerd 에 대한 지원을 해줬지만, 1.24 버전부터 Dockerd 에 대한 지원을 제공하지 않고, Containerd 에 대한 지원만 제공한다
-
배포 자동화를 위해서는 ' 형상 관리 도구 ' 가 필요하다
- 형상 관리 도구는 COMMIT 이 발생시 해당 내용을 가져와서 이미지를 생성하고, 해당되는 컨테이너를 Rolling Update 한다
- 이걸 가능하기 위해 형상 관리 도구와 컨테이너 사이에 파이프 라인을 구성해야 한다
-
ci 는 지속적 통합, cd 는 지속적 배포 이다. 이 지속적 통합과 배포는 개발한 프로그램의 빌드, 테스트, 패키지화, 배포 단계를 모두 자동화하여 개발 단계를 표준화해준다
- 보통 github 와 jenkins 를 같이 사용하거나, 설치형 형상 관리 도구인 gitlab 과 jenkins 를 같이 사용하는 방식을 많이 사용한다
-
모니터링 도구에는 프로메테우스와 그라파나가 있다. 모니터링 데이터 수집 도구는 프로메테우스가 주로 쓰이며, 데이터 시각 도구에는 그라파나, 키바나 등이 있다
2. Helm
Pod 와 생성되는 Object
-
K8S 의 최소 서비스 단위는 Pod 이다. 이 Pod 에는 최소 단위인 컨테이너들이 들어가있다
- Pod 는 한 개 이상의 컨테이너의 집합 이다
-
Pod 와 함께 Service Object 를 생성해야 하는데, 이곳에는 Cluster-Ip , node port, LB 가 들어가있다
-
또한, Pod 를 위한 PV Object, Configmap, Secret 등의 Object 들이 있다
- 이외에도 애플리케이션 배포를 위해 생성해야 하는 것들이 많다
Centos 는 yum 을 이용해 Package 설치, Ubuntu 에서는 apt 를 이용하여 Package 설치하여 간단하게 설치한다. 이와같이 K8S 에서도 Service 배포를 helm 을 이용하여 간단하게 설치가 가능하다
helm ( 헬름 )
-
Helm 을 이용하면 K8S 에서 애플리케이션 배포를 위한 모든 요소가 들어간 패키지를 설치할 수 있다
- 이때, set 옵션을 통해 기본 제공하는 옵션을 변경할 수 있다
-
Helm 은 K8S 환경에서 Pod, Service, Configmap, Secret, PV / PVC 등을 하나 하나 설치하는 방법이 아닌 일종의 패키지 형식으로 간단히 설치하는 방법을 제공한다
- 이는 CENTOS 의 YUM 을 이용하여 배포하는 것과 비슷한 원리이다
3. K8S 구성 방법
Swarm mode 와 K8S 의 Node Role
-
Swarm mode 에서는 role 이 manager , worker 로 지정된다
-
K8S 에서는 role 이 master , worker 로 지정된다. worker 는 node 라고도 부른다
- Swarm mode 에서의 manager 는 worker 의 역활을 수행할 수 있지만, master 는 worker 의 역활을 수행할 수 없다
K8S 구성 방법
-
퍼블릭 클라우드 업체에서 제공하는 완전 관리형 서비스이자 관리형 쿠버네티스인 EKS, AKS, GKE 들을 사용
- GKE 는 GOOGLE 에서 제공하는 완전 관리형 서비스로, 서비스 요청시 서비스가 바로 제공이 된다. 이는 k8s 에는 접속 가능하지만, 밑에 있는 OS 나 물리 자원에는 접근이 불가능하다
-
Rancher 나 Openshift 와 같은 플랫폼에서 제공하는 설치형 쿠버네티스
-
쿠버네티스 클러스터를 자동으로 구성해주는 솔루션 사용. 주로, kubeadm, kops, KRIB, kubespray 등이 있으며, kubeadm 을 주로 사용한다. 이러한 솔루션들을 구성형 쿠버네티스 라고 한다
4. K8S 구성 요소
P. 96
Kubeadm을 이용해 Kubernetes를 설치하면, 각 컴포넌트는 다음과 같은 형태로 설치된다
| 컴포넌트 | 형태 | Node |
|---|---|---|
| Api Server | Static Pod | Master Node |
| Kube Scheduler | Static Pod | Master Node |
| Controller Manager | Static Pod | Master Node |
| ETCD | Static Pod | Master Node |
| Kubelet | Linux Daemon | Master Node, Worker Node |
| KubeProxy | DaemonSet | Master Node, Worker Node |
Master Node 컴포넌트들은 Kubeadm을 이용해 Static Pod로 배포하는 방법과 바이너리 파일을 이용해 Linux Daemon으로 설치하는 방법이 있다. 이외에도 여러 방법이 존재한다
Master Node 구성 요소
-
kubectl : K8S 클러스터에 명령을 내리는 역활. 이를 통해 K8S API 서버에 API 로 명령을 내린다
-
API 서버 : 쿠버네티스 클러스터의 중심 역활을 하는 통로. 모든 요소들은 API 서버를 중심에 두고 통신한다
-
etcd : 구성 요소들의 상태 값이 모두 저장된 곳으로, 분산 저장이 가능한 key-value 저장소이다. 이 etch 의 정보의 백업을 통해 K8S 클러스터를 복구할 수 있다
-
스케줄러 : Node 의 상태와 자원, label 과 요구 조건을 고려해 Pod 를 어떤 Node 에 생성할지 결정하고 할당
-
컨트롤러 매니저 : 오브젝트 상태를 관리
- 노드 컨트롤러 : 상태 체크와 복구
- 레플리카셋 컨트롤러 : 레플리카셋에 요청받은 Pod 개수대로 Pod 생성
- 엔드포인트 컨트롤러 : Service 와 Pod 연결
Master Node에도 Kubelet과 Kube-Proxy가 존재한다
- Kubelet은 Pod를 관리하는 Kubernetes Agent이다. Kubeadm을 이용해 Kubernetes를 설치하게되면, ETCD / Api Server 등 Master Node Component 들이 Kubelet Daemon에 의해 Static Pod로 배포되어지고, 관리되어진다. 따라서 Master Node에도 Kubelet이 존재한다
- Master Node는 일반적으로 클러스터 내의 Worker Node로도 구성되어진다. 따라서 Master Node에도 Kubelet, Kube-Proxy, Container Runtime 이 실행된다
Worker Node 구성 요소
-
Kubelet : 명령을 전달 받아서 컨테이너 Runtime 으로 전달해준다. Master Node 는 Worker Node 의 Kubelet 과 통신한다. Kubelet은 Pod를 관리하는 Kubernetes Agent로, Pod가 아닌 리눅스 Daemon으로 동작한다
-
KubeProxy : 각 Node 마다 DaemonSet Controller가 관리하는 Pod로 존재한다. Kube Proxy는 Linux의 Netfilter와 Iptables를 이용해 서비스가 가지고 있는 Virtual Ip로 트래픽을 전달할 수 있게 해주며, 클러스터 내부 Ip 로 연결하려는 요청을 포워딩과 로드밸런싱을 통해 적절한 파드로 전달해주는 프록시 및 로드밸런서 역할을 하는 컴포넌트이다
- Kubernetes에서 네트워크 동작을 관리하는 컴포넌트이다
-
Container Runtime : Pod 를 이루는 컨테이너의 실행을 담당하며, 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스이다. 이 CRI 에 맞게 개발해야 한다
- 최신 버전의 K8S 에서는 Docker 와 관련된 CRI 중에서 Dockerd 가 사라지고, Containerd 만 남았다
-
POD ( 포드 , 파드 ) : 한 개 이상의 컨테이너의 조합으로 애플리케이션 배포의 최소 단위이다. 일반적으로는 한 개의 주 컨테이너와 다른 한 개의 보조 컨테이너로 연결되며, 보조 컨테이너는 side-car 라고 부른다. 주로 주 컨테이너를 모니터링하거나, 로그 수집 등에 활용된다
- POD 내에 있는 컨테이너는 별도의 Node 로 분리되지 않는다
선택 가능한 구성 요소
-
네트워크 플러그인 : 일반적으로 CNI 로 구성되며, K8S 클러스터의 통신을 위해 사용된다. 이는 POD 간 Overlay 통신을 위한 외부 플러그인이다. 주로, CALICO 를 사용한다
-
CoreDNS : 빠르고 유연한 DNS 서버. Node 내에 있는 CoreDNS 는 각 POD 별로 이름을 부여하고, 해당 이름에 대한 IP 정보를 매핑하여 보관한다. 따라서 POD 간 통신시, 각 POD 의 IP 정보를 확인할 필요없이 이름으로 접속할 수 있게 된다
Node 외부에서 Pod 와 통신할 때, Node 안의 Kube-Proxy 를 통해 Pod 와 통신한다. Pod 또한 외부로 직접 나가는 것이 아닌, Node 의 Proxy 와 통신한다. 이때, 외부 사용자는 Pod 가 어떤 Node 에 위치하는지 몰라도 된다
5. Kubernetes 기본 사용법
p. 106
K8S 를 사용하는 것은 사용자에게 POD 를 제공하는 것이다
- K8S 에서는 모든 오브젝트 ( POD, REPLICASET, DEPLOYMENT, SERVICE, CONFIGMAP / SECRET, PV / PVC ... ) 는 YML 파일 형태로 작성하여 배포가 가능하다. 이를 " Manifest File " 이라 부른다. 물론 명령을 통해서도 배포는 가능하지만, 재사용 등을 고려했을 때 파일 작성을 추천한다
- create 는 명령형이나 파일을 불러와서 배포하는 형으로 활용
- apply 는 파일을 이용하는 배포에 활용
6. Container 와 Pod 차이점
Container
Container 는 다양한 Runtime 을 통해 만들어진다
- 하나의 Container 는 하나의 애플리케이션으로, 이 Container 를 배포한다고 한다
- 하나의 Container 에는 한 개의 namespace 가 할당
- 생성과 즉시 Port Forwarding 을 통해 외부와 연결 가능
Pod
Pod 는 K8S 에서 만들어진다
- 하나의 Pod 는 한 개 이상의 Container 의 그룹이다. Pod 는 한 개의 namespace 가 할당되며, 내부의 Container 들은 한 개의 namespace 를 공유한다. 따라서, 해당 Container 들은 떨어질 수 없다
- 한 개의 Pod 에는 한 개의 Ip 가 할당되며, 내부의 다수의 Container 들에 접근하기 위해서는 Port 를 통해 접근한다
- 외부에서 해당 애플리케이션을 생성과 즉시 노출시킬 수 없으며, 이를 위해서는 별도의 Service Object 를 이용해야 한다. 이 Service 의 Type 으로는 clusterIp, nodePort, LB ( 일반적으로 Public Cloud 에서 활용, on-premise 에서는 metallb 를 이용하여 환경 구성 가능 ) 이 있다
- Pod 는 하나의 Service 로, 다수의 컨테이너를 묶은 하나의 애플리케이션이다
Pod 생성시 master 에서 Pod 를 생성하여, namespace 등을 지정하여 worker 의 kubelet 에 해당 정보를 전달해준다. worker 는 runtime 을 통해 Pod 에 속할 container 를 배포한다
1개의 댓글
