K8s 기본 개념 – System Tour

안녕하세요! K8s 에 대하여 공부하고 예전 구글 gcp 쿠버 공부 관련하고자 여러 곳을 참고 및 정리하여 작성하였습니다.

K8s 란

컨테이너 자동화하기 위한 컨테이너 오케스트레이션 도구 입니다.

오케스트레이션 이란?

컨테이너 배포 관리 하며, 목적 으로는 여러 컨테이너의 배포 프로세스를 최적화 하는데 있으며, 이것은 컨테이너와 호스트의 수가 증가함에 따라 점점 더 가치가 있게 됩니다. 이러한 유형의 자동화를 오케스트레이션이라고 합니다.

기능

K8s 중요 부분

쿠버네티스로 실행하는 애플리케이션은 애플리케이션을 구성하는 다양한 리소스가 함께 연동해 동작함, 여기서 말하는 쿠버네티스의 리소스란 애플리케이션을 구성하는 부품과 같은 것으로 노드, 네임스페이스, 파드 등 이 있습니다.

K8s 용어

master

마스터 노드이다. 다중 도커데몬을 관리하는 일을한다. (cloud 같은경우는 cloud 업체에서 관리 합니다.)

(클러스터(노드)에 관한 전반적인 결정을 하고 이벤트를 감지 및 반응하는 역할)

worker

도커가 설치되어 있으며 실제 컨테이너들이 생성되어 일하는 노드입니다 예전에는 minion이라는 이름을 가지기도 하였습니다. 마스터의 관리를 받고 있습니다.

pod (=서버 , pod 100개 생성 할려면 IP 100개 필요하다.)

-kubernetes의 기본 단위입니다. 컨테이너 혹은 컨테이너의 묶음이라고 불립니다.

-kubernets의 특징중 하나는 container를 개별적으로 하나씩 배포하는 것이 아니라 pod 단위로 배포합니다. [결합이 강한 컨테이너를 파드로 묶어 일괄 배포합니다.(ex spring web app + nginx)]

-pod가 날라가면 안에 있는 데이터도 날라간다 그게 싫으면 pv ,pvc를 해야한다.

추가적으로 pod는 노드에 배치 됩니다.

한 pod 안의 컨테이너는 모두 같은 노드에 배치되며, pod 하나가 여러 노드에 걸쳐 배치될 수는 없습니다.

함께 배포해야 정합성을 유지할 수 있는 컨테이너 등에도 해당 컨테이너를 같은 팟으로 묶어두는 전략이 유용합니다. (ex) 리버스 프록시 역활 nginx 와 그 뒤에 위치할 애플리케이션 컨테이너를 함께 pod로 묶는 구성)

rc는 replication controller의 줄임말입니다. pod를 자동으로 생성 복제해주는 컨트롤러입니다. 복제 개수 설정을 3으로 하게 되면 3개의 pod가 서비스상에 계속 active상태가 됩니다.

service

pod의 group을 식별하는 라벨이라는 기준에 따라 pod들을 하나의 서비스로 외보에서 접근할 수 있도록 해줍니다.

yaml

kubenets에서 service, rc, pod등 기능을 설명한 데이터 형식 코드입니다. 야믈이라고 읽습니다.

네임스페이스

쿠버네티스는 클러스터 안에 가상 클러스터를 또 다시 만들 수 있다. 이 클러스터 안의 가상 클러스터를 네임스페이스라고 함, 클러스터를 처음 구축하면 default, docker, kube-public, kube-system의 네임스페이스 4개가 이미 만들어져 있다. kubectl get namespace 명령으로 현재 클러스터 안에 존재하는 네임스페이스의 목록을 확인할 수 있습니다.

ㄴ> 전체 클러스터에서 특정 이름으로 클러스터의 영역을 구분한거라고 생각하면 되겠습니다.

클러스터와 노드

클러스터는 1개 이상의 클러스터 마스터 머신과 노드라는 여러 작업자 머신으로 구성됩니다. 노드란 클러스터를 구성하기 위해 필요한 Kubernetes 프로세스를 실행하는 Compute Engine 가상 머신(VM) 인스턴스입니다.

⇒ 클러스터는 쿠버네티스의 여러 리소스를 관리하기 위한 집합체를 말한다.

⇒ 노드는 클러스터의 관리 대상으로 등록된 도커 호스트로, 도커 컨테이너가 배치되는 대상이다.

⇒ 쿠버네티스는 노드의 리소스 사용 현황 및 배치 전략을 근거로 컨테이너를 적절히 배치합니다. 다시 말해 클러스터에 배치된 노드의 수, 노드의 사양 등에 따라 배치할 수 있는 컨테이너 수가 결정된다는 뜻입니다.

pod생성 yaml

k8s의 apiversion은 보통 v1을 사용하며, kind는 리소스 종류를 정의하게 됩니다. pod및 service 등이 있습니다. metadata 에는 리소스의 각종 메타 데이터인 name, resource, label등이 있습니다.

하단에 spec은 resource등의 대한 상세정보를 정의하면 되며, container이름은 gpu-test로 정의하고 docker image는 1985ck/gpu-test:1.0을 사용하겠다. 또한 컨테이너포트 8000을 열겠다고 정의한 것입니다.

pod – replicaset (=replicaset(복제) 은 100개 설정 하면 pod 100개만듬)

위 그림을 예로 할경우 web container를 2개 복제해서 띄어놓겠다 라고 정의하여 pod를 생성하게 되면 2개의 호스트에 container가 생성되서 서비스를 하며,

만약 container나 서버가 다운되게 되면 10.244.2.4의 호스트에 컨테이너가 바로 생성이 됩니다

K8s 구성요소

Master Node : 쿠버네티스의 주요 컨트롤 유닛으로서 worker nodes를 관리하는 주체이며, 클러스터에 관한 전반적인 결정을 하고 이벤트를 감지 및 반응하는 역할을 합니다.
Worker Node : 워커노드는 할당된 task를 요청대로(실행할 작업) 수행하는 시스템인데요. 컨테이너들간의 네트워크 등 서비스에 필요한 전박적인 일을 마스터 노드와 통신하며 수행합니다.

Master	worker
kubectl, api server, scheduler, controller manager, etcd	kubelet, kube-proxy, pod

Kubectl: 마스터 노드와 통신하는 명령어로서 쿠버네티스 API를 사용해서 마스터노드와 상호작용을 합니다.
API Server: REST API 요청을 처리하고 쿠버네티스 클러스터를 구성하는 각 컴포넌트들과 통신을 담당합니다.
Scheduler :노드들의 리소스 상태를 파악하여 pod가 배치될 적절한 노드를 선택해 주는 역할.
Controller Manager: 쿠버네티스 클러스터 상태 감시, 설정한 상태로 유지하는 역할.
ETCD :오픈소스 key-value 저장소로서 Kubernetes에서는 Master Node의 API Server가 HTTP/JSON API를 이용하여 접근할 수 있는 구성 데이터를 저장하는 용도로 사용됩니다.
Kubelet: 쿠버네티스 마스터 노드간의 통신을 담당하는 에이전트로서 노드에서 동작하는 pod들을 관리합니다.
Kube-proxy :각 노드별로 탑재되며 네트워크 프록시 및 로드밸런서 역할을 해줍니다. Pod- Pod는 컨테이너의 그룹으로 한 개 또는 여러 개의 컨테이너를 포함하는 쿠버네티스의 작업단위 입니다.

K8s pod 생성 과정

ㄴ> pod생성 과정 architecture입니다.

–Kubernetes에서는 다음과 같은 컴포넌트가있습니다.

API 서버: Kubernetes 시스템의 중심이며, 모든 클러스터 관리 작업에 대한 엔드포인트입니다.
etcd: 분산 데이터 스토어로서, API 서버와 다른 Kubernetes 컴포넌트 간의 모든 데이터를 저장합니다.
스케줄러: Pod을 노드에 할당하는 역할을 합니다.
컨트롤러 매니저: 클러스터 상태를 감시하고, 상태에 따라 필요한 작업을 수행합니다. 예를 들어, Replication Controller는 Pod을 실행하고, Replication Set은 Pod의 복제본을 관리하고, Daemon Set은 각 노드에 특정 Pod을 배포합니다.
kubelet: 각 노드에서 실행되며, 노드의 상태를 모니터링하고, Pod의 실행을 관리합니다.
kube-proxy: 클러스터의 네트워크를 관리하며, 각 노드에서 실행되는 Pod과의 통신을 관리합니다.

이러한 컴포넌트는 Kubernetes 클러스터에서 각기 다른 역할을 수행하며, 애플리케이션 배포 및 관리에 필수적입니다. 이러한 컴포넌트는 Kubernetes의 유연성과 확장성을 보장하며, 애플리케이션의 안정성 및 가용성을 향상시킵니다.

디플로이먼트 (=배포 관리(카나리아 등) , 레플리카셋 관리함)

Deployment는 쿠버네티스에서 가장 널리 사용하는 오브젝트 중 한개 입니다.
레플리카셋(ReplicaSet) 컨트롤러와 레플리케이션(Replication) 컨트롤러는 파드를 생성하고 관리합니다. 레플리케이션 컨트롤러보다 더 상위 수준의 컨트롤러 리소스가 있습니다. 그것이 디플로이먼트(Deployment) 리소스 입니다.

““““오브젝트 란?`

쿠버네티스의 오브젝트(objects)는 클러스터의 상태를 나타내는 단위(entities)입니다.

오브젝트는 “의도를 담은 레코드”입니다. 생성된 클러스터는 그 의도대로 존재할 수 있도록 최선을 다합니다. 이는 클러스터의 “의도한 상태(desired state)“라고 알려져 있습니다.

쿠버네티스는 항상 오브젝트의 “현재 상태”를 “의도한 상태”와 동일하게 만들게끔 작동합니다. 이때 의도한 상태란 다음과 같습니다.

어떤 파드(컨테이너)들이 어느 노드에서 동작(running) 중인지
컨테이너들의 논리 그룹과 매핑된 IP 엔드포인트
동작 중인 컨테이너 레플리카(replicas)의 개수
기타 다수 상태들…

디플로이먼트 매니페스트

Kubernetes에서는 애플리케이션을 배포하고 관리하기 위해 매니페스트 파일을 사용합니다. 디플로이먼트 매니페스트는 Kubernetes 클러스터 내에서 애플리케이션을 배포하는 데 사용되는 YAML 파일입니다.

배포전략

Rolling

Rolling 배포는 서버를 한 대씩 구 버전에서 새 버전으로 교체해가는 전략이다. 서비스 중인 서버 한 대를 제외시키고 그 자리에 새 버전의 서버를 추가하며, 이렇게 구 버전에서 새 버전으로 트래픽을 점진적으로 전환합니다. 이와 같은 방식은 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스의 수가 감소 되므로 서버 처리 용량을 미리 고려해야 합니다.

Blue/Green

Blue/Green 배포는 구 버전에서 새 버전으로 일제히 전환하는 전략입니다. 구 버전의 서버와 새 버전의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시키며, 하나의 버전만 프로덕션 되므로 버전 관리 문제를 방지할 수 있고, 또한 빠른 롤백이 가능합니다. 또 다른 장점으로 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능하며, 예를 들어 구 버전과 새 버전을 모두 구성하고 포트를 다르게 주거나 내부 트래픽일 경우 새 버전으로 접근하도록 설정하여 테스트를 진행해 볼 수 있습니다.. 단, 시스템 자원이 두 배로 필요하고, 전체 플랫폼에 대한 테스트가 진행 되어야 합니다.

Canary

Canary는 카나리아 라는 새를 일컫는 말인데, 이 새는 일산화탄소 및 유독가스에 매우 민감하다고 한다. 그래서 과거 광부들이 이 새를 옆에 두고 광산에서 일을 하다가 카나리아가 갑자기 죽게 되면 대피를 했다고 합니다. Canary 배포는 카나리아 새처럼 위험을 빠르게 감지할 수 있는 배포 기법이며, 구 버전의 서버와 새 버전의 서버들을 구성하고 일부 트래픽을 새 버전으로 분산하여 오류 여부를 판단합니다. 이 기법으로 A/B 테스트도 가능한데, 오류율 및 성능 모니터링에 유용하다. 트래픽을 분산시킬 라우팅은 랜덤으로 할 수도 있고 사용자 프로필 등을 기반으로 분류할 수도 있으며, 분산 후 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 돌아가 수도 있습니다.

읽어주셔서 감사합니다

Kubernetes in Google Cloud