Google과 컨테이너
• Google의 업무 방식
• Gmail에서 YouTube, 검색에 이르기까지 모두 컨테이너에서 실행
• 개발팀은 컨테이너화를 통해 더욱 신속하게 소프트웨어를 배포
• 매주 수십억 개가 넘는 컨테이너를 생성
• 쿠버네티스
• 대규모 워크로드를 운영/관리한 경험과 노하우가 축적된 다년 간의 프로젝트로 컨테이너를 통합 관리함
• 그리고 2014년 오픈소스 프로젝트로 외부로 공개
• Go로 작성된 오픈소스 SW (Apache License 2.0)
• Cloud-Native Computing Foundation (CNCF) 에서 관리
• 컨테이너 배포, 네트워크, 스토리지 관리 정책을 세부적으로 명세 가능 (네트워킹 제공x => 정책들을 관리)
• 대규모의 클러스터 운영이 가능하도록 확장성이 매우 높음
• 클라우드와의 연계성이 매우 높아 서비스를 이식하기에 용이함
주요 기능
1. Auto Scale Out / In 2. Load Balancing 3. Auto Rolling Update
Q. 쿠버네티스가 로드 밸런싱을 직접하나?
A.로드 밸런싱을 하는것은 쿠버네티스 안에 따로 있다. 즉, 쿠버네티스는 관리할 수 있게 해주는 것
4. Auto Healing 5. Persistence Volume 6. Container Orchestration
• 상태 관리
• 상태를 선언하고 선언한 상태를 유지, 자동 장애 복구
• 스케줄링
• 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너를 배치
• 클러스터
• 가상 네트워크를 통해 하나의 서버에 있는 것처럼 통신
• 서비스 디스커버리
• 서로 다른 서비스를 쉽게 찾고 통신할 수 있음
• 스케일링
• 리소스에 따라 자동으로 서비스를 조정함
• Roll Out / Roll Back
• 배포/롤백 및 버전 관리
등의 기능들도 있다.
Immutable Infrastructure
-> 컨테이너 환경을 써야 되는 이유를 설명
- Configuration Drift (설정 표류?)
• 손으로 직접 수정한 임시 수정/업데이트와 전반적인 엔트로피 증가로 인해 인프라의 서버들의 시간이 갈수록 점점 서로 다른 상태가 되는 현상
• 장비의 라이프사이클 동안 초기 설정으로부터 멀어지고 다른 장비들과 서로 달라짐 - Immutable Infrastructure (불변의 인프라?)
• 서버가 배포된 이후 절대 변경되지 않는 형태의 인프라 패러다임
• 업데이트는 덮어 쓰는 것이 아니라 버리고 새롭게 만드는 것 - Disposable Components (폐기 가능한 구성요소?)
• 애플리케이션을 구성하는 개별 구성요소
• 상태 정보를 가지지 않는 무상태(stateless) 방식으로 설계 => 추후 MSA형태로 발전
Kubernetes Reconciliation Model
쿠버네티스는 관리를 위한 용도이다. 즉, 어떤 상태인지 얘기를 해주는게 쿠버네티스이고 그 밑에 컨테이너 플랫폼이 그걸 보고서 핸들링을 하고 컨테이너 네트워킹 플랫폼이 그 상태를 보고서 판단을 한다. 따라서 쿠버네티스는 현재 상태를 계속 모니터링하고 조정,관리한다.
Kubernetes Architecture
Master Node
- 클러스터에 관한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응
- kube-api-server
• Control Plane의 프론트 엔드, Kubernetes의 API 노출 - kube-scheduler
• 노드가 배정되지 않은 새로 생성된 Pod를 감지하고, 실행할 노드를 선택 - kube-controller-manager
• Kubernetes의 컨테이너들을 관리, 노드 다운 시 통지와 대응에 관해 책임
• 시스템의 모든 컨테이너를 설정된 정책의 숫자에 맞게 유지
• 시스템 네임스페이스 관리 - etcd
• Kubernetes에서 필요한 모든 데이터를 키-값 형태로 저장
Worker Node
- 동작 중인 컨테이너를 유지시키고 Kubernetes 런타임 환경을 제공
- kubelet
• 클러스터의 각 노드에서 실행되는 에이전트
• 다양한 메커니즘을 통해 제공된 컨테이너의 스펙의 집합을 받아서 컨테이너가 항상 스펙에 따라 동작하도록 모니터링 - kube-proxy
• 클러스터의 각 노드에서 실행되는 네트워크 프록시
• 노드의 네트워크 규칙을 유지
• 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 Pod로 네트워크 통신을 할 수 있도록 해 줌 - Container runtime
• 컨테이너 실행을 담당하는 소프트웨어
• docker, containerd, CRI-O를 구동
컨테이너 런타임 인터페이스라고도 얘기하는데 실질적인 액션을 담당하고 쿠버네티스는 마치 API콜을 하는것 즉, 무슨 상태를 원해! => 도커나 컨테이너나 크리오 같은 애들이 수행
Objects
- 오브젝트
• 리소스의 가장 기본적인 구성 단위
• 시스템에서 영속성을 가지는 객체 - 기본 오브젝트
• Pod
• 가장 기본적인 배포 단위, 하나의 Pod은 하나의 노드에만 배치
• Pod에 하나 이상의 컨테이너 포함 가능, IP와 Port, 볼륨 공유
• Service
• 외부 네트워크와 내부 네트워크의 Endpoint 관리
• 잦은 Pod 교체에도 네트워크 상태 유지
• Volume
• 논리 디스크, 잦은 Pod 교체에도 디스크의 영속성 보장
• Namespace
• 클러스터 내 논리적인 공간 단위, 개별 접근 권한 및 리소스 할당량 제어
Controllers
- 컨트롤러
• 오브젝트의 상태가 의도된 상태로 구동되는지를 추적
• 의도한 상태로 만드는 역할 -> Kubernetes Reconciliation Model
- 컨트롤러의 종류
• Replica Set
• Pod 집합의 실행을 항상 안정적으로 유지
• 명시된 Pod 개수에 대한 가용성을 보증
• Deployment
• Pod과 ReplicaSet에 대한 선언적 업데이트를 제공
• ReplicaSet이 의도한 Pod의 개수를 조정
• ReplicaSet의 Roll-Out을 통해 시스템의 스케일을 관리
• DaemonSet
• ReplicaSet과 비슷하지만, 노드마다 Pod의 개수만큼 실행
• 애플리케이션이 클러스터 전체 노드나 특정 집합에서 동작할 때 사용
• StatefulSet
• Deployment와 유사하게 스케일링을 관리, Pod들의 순서 및 고유성 보장
• 애플리케이션의 순차적인 배포에 적합
• Job
• 하나 이상의 Pod을 생성하고 지정된 수의 Pod이 성공적으로 종료될 때까지 계속해서 Pod의 실행을 재시도
• Pod이 성공적으로 완료되면, 완료된 Job을 추적
• Job이 성공적으로 완료되면, Job이 완료 상태로 변경
• Job을 삭제하면 Job이 생성한 Pod도 정리
Kubernetes Networking
- Container Network Interface (CNI)
• 컨테이너 간 네트워킹을 제어할 수 있는 플러그인
• Container Runtime과 Kubernetes 사이의 네트워크 계층 구현 - Service 종류
• ClusterIP – 클러스터 내부에서 다른 Pod들이 접근하기 위한 IP
• NodePort – Node의 고정 포트로 Pod의 서비스를 노출
• LoadBalancer – 별도의 로드밸런서를 통해 서비스를 외부로 노출 - CNI 종류
'CS > 클라우드 컴퓨팅' 카테고리의 다른 글
| [클라우드] 8. 스토리지 가상화 (Storage Virtualization) (0) | 2024.05.10 |
|---|---|
| [클라우드] 7. 현대 네트워크 가상화 (Modern Network Virtualization) (1) | 2024.05.01 |
| [클라우드] 5. 네크워크 가상화(Network Virtualization) (0) | 2024.04.04 |
| [클라우드] 4. Container (Docker) (0) | 2024.03.21 |
| [클라우드] 3. 서버 가상화(Server Virtualization) (0) | 2024.03.21 |
댓글