1. worker node
워크로드가 돌아가는 컨테이너를 배치하는 물리(가상) 머신
- control plane에 의해 관리됨.
- 일반적인 운영환경에서는 multi node로 운영
- 각 노드는 kube-proxy, container-runtime, kubelet이 포함.
2. namespace
동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원하는 개념
- 클러스터를 논리적으로 나누고 액세스를 제한하여, 리소스 생성 및 관리
- 논리적으로 구별될뿐 격리되는 것이 아님.
(격리 시키기 위해서는 network policy와 같은 오브젝트를 추가로 사용해야함.)
3. Pod
kubernetes 최소 단위 객체
- 하나의 pod는 여러 컨테이너 포함 가능
- MSA의 decoupling에 의하면 사실상 1 pod 당 1 container가 정석이다.
하나의 pod안에서 동작하는 특정 컨테이너의 로그를 수집해야하는 경우에는
상황에 따라 해당 pod에 두 개의 컨테이너를 배치해야할 수도 있다.
- 이럴 때를 위해서 권장되는 공식 디자인 패턴이 존재한다.
SideCar 디자인 패턴
- pod 안에서는 파일 시스템을 공유 하기 때문에
특정 컨테이너의 로그를 파일 시스템에 넣고 로깅 컨테이너가 해당 파일 시스템으로 부터 파일을 조회하는 패턴.
Adapter 디자인 패턴
- 특정 컨테이너의 데이터 형식을 변환하여 외부로 반환
Ambassador 디자인 패턴
- 특정 컨테이너를 대신하여 외부 통신을 중재한다.
굳이 두 개의 컨테이너로 하지않고 하나의 컨테이너가 전부 해도 된다.
하지만 "하나의 컨테이너는 하나의 성격을 가진다" 라는 이념에 어긋나기 때문에,
컨테이너 decoupling을 할 때는 이런 식의 패턴으로 구성하는 것이best practice라고 권장한다.
4. replicaset
pod의 레플리카를 생성하고 지정한 pod의 수를 유지하는 리소스
5. Deployment
복제된 (replicated) 애플리케이션 (pod)를 관리하는 오브젝트
- 롤링 업데이트나 롤백 등을 구현하는 리소스
- maxUnavailable : 업데이트 중 동시에 정지 가능한 최대 pod 수
- maxSurge : 업데이트 중 동시에 생성할 수 있는 최대 pod 수
6. Daemonset
클러스터의 각 노드에 pod를 하나씩 띄울 때 사용하는 오브젝트
- 로그 수집기를 실행하거나 노드를 모니터링하는 모니터링용 데몬 등 클러스터 전체에 항상 실행시켜 두어야하는 pod를 실행하는 데 사용
- 대표적인 daemonset : kube-proxy, fluent-bit
7. Service
Pod의 집합과 같은 어플리케이션에 접근 경로나 Serice Discovery를 제공
- Pod를 외부 네트워크에 연결하고 pod로의 연결을 로드 밸런싱하는 네트워크 오브젝트
- 하나의 MicroSerivce 단위
서비스 노출 타입
Cluster Ip Type
- 기본 kubernetes 타입이고 cluster 내부에서만 통신이 가능한 internal network 가상 Ip 할당.
- service - pod간 통신은 kube-proxy가 담당
- 보통 서비스 테스트나 디버깅 용으로 사용
NodePort Type
- NAT을 이용해 클러스터 내 Node에 고정된 port를 갖는 Ip로 service를 외부에 노출
- 외부 트래픽을 서비스에 전달하는 가장 기본적인 방법
- 클러스터 외부에서 접근은 [Node Ip]:[Node Port]
- 포트 사용 범위: 30000 ~ 32767
일반적인 웹 서비스라면 80 또는 443을 사용하기 때문에, NodePort 방식으로 서비스를 노출하게 되면 접근하려는 클라이언트가 매번 3000이 넘는 포트를 기억해서 url 끝에 달아줘야한다.
- 즉, NodePort 방식도 일반적인 서비스 용도로는 적합하지 않다.
LoadBalancer Type
- 클라우드 공급자의 로드밸런서를 이용해 service를 외부로 노출
- 외부 로드밸런서를 이용하기 때문에 SPOF에 강함
- L4 (TCP) or L7(HTTP) 계층을 통해 서비스 노출
8. Ingress
Service Type은 아니지만, Service 앞에서 Smart Router 및 entry point 역할을 하는 오브젝트
- 외부에서 접근 가능한 url, 로드밸런싱, SSL Termination 등을 통해 Service에 대한 HTTP 기반 접근을제공
- 클러스터에 하나 이상의 실행 중인 Ingress Controller가 필요
Why Ingress?
/user, /order 등 다양한 서비스 들이 존재하는 MSA 일 때 각각에 로드밸런서를 생성하는 건 좋지 않다. 그래서 하나의 로드밸런서를 두고 호스트를 기반으로 트래픽을 분기하기 위해 Ingress를 사용한다.
- AWS의 ALB를 Ingress로 사용하면 된다. ( Target Group )
9. CA (Cluster Autoscaler )
수요에 따라 kubernetes 노드를 자동으로 추가하는 기능
- 리소스 부족으로 pod의 노드 할당이 pending 될 때 (scale-out)
- 미사용 node가 있을 때 (scale-in)
- 각 클라우드 provider 마다 각자의 cluster autoscaling 방법이 있음
AWS의 경우 EC2 ASG로 CA를 구현하지만 가장 기본적인 방법이고 CA가 AWS의 ASG에 의존성이 높아지고 node가 새로 뜨는데 시간이 오래걸린다.
- 그래서 다른 툴들을 사용한다.
10. metricserver_hpa_vpa
kubernetes 클러스터 리소스 사용량 데이터를 집계하는 역할
- 리소스의 metrics (CPU 사용량, 메모리 사용량 등)을 수집하고 metric API를 통해 apiserver에 노출하여 horizontal pod Autoscaler 및 vertical pod Autoscaler에서 활용
- 클러스터 내에서 Deployment 형태로 설치
HPA ( Horizontal Pod Autoscaler )
- Deployment / Replicaset의 레플리카 수를 CPU / 메모리 부하 등에 따라 자동으로 스케일 해주는 오브젝트
- Pod의 Resource Request를 기준으로 동작
- metric-server에서 가져온 각 파드의 1분 평균값
HPA 기준
- cpu (resource)
- memory (resource)
- packets-per-second (pod)
- requests-per-second (ingress)
VPA ( Vertical Pod Autuscaler )
- HPA와 달리 scale-up을 해주는 오브젝트
- 서비스 초기 단계에서 Resource Request에 어떤 값이 적정한지 명확하지 않을 때 유용하다.
11. 환경 변수
개별 컨테이너에 설정해야하는 내용을 환경 변수로 전달
- Timezone, DB 접속 정보 등
- pod 정의 파일에 환경변수를 지정하거나 설정 파일을 마운트하여 전달
12. configmap
워크로드에 필요한 설정 정보를 key-value 형태로 저장할 수 있는 데이터 오브젝트
- 간단한 환경변수부터 nginx.conf와 같은 파일도 저장 가능
13. secret
워크로드에 필요한 민감정보를 key-value 형태로 저장할 수 있는 데이터 오브젝트
- base64 인코딩 상태로 저장
14. Volume
스토리지 볼륨을 추상화하여 pod와 느슨하게 결합시킨 리소스
- 오브젝트 형태가 아닌 pod 내에서 정의
