메프도의 요약노트
k8s.pdf
drive.google.com
쿠버네티스 까지의 역사
- Borg(2014)
: Google에서 개발한 최초의 통합 컨테이너 관리 시스템
> 자원 요구사항 예측 : 리소스 활용도↑ 비용 효율적인 배포
> Configuration 파일을 실행중인 서비스에 동적 반영 가능
> *서비스 디스커버리, 로드밸런싱, 자동 스케일 Up/Down 등 제공
- Omega
> Borg에서 클러스터 상태 저장 기능이 추가됨 : 클러스터 상태 일관성
> 2명 dl상의 동시 리소스 접근 : *낙관적 동시성 제어 도입
- Kubernetes
> Borg, Omega와 달리 오픈소스
> 리소스 변경 저장을 위한 공유 영구 저장소 존재 but 직접접근X
> REST API를 통해서만 영구 공유 저장소 접근 가능
> 다수의 컨테이너화 된 애플리케이션을 자동 배포/스케일링
* 서비스 디스커버리?
| MSA와 환경에선 많은 애플리케이션이 종료/재시작 됨 애플리케이션 실행 노드 또한 매번 변경 => Service Registry 서버 존재 * 레지스트리 서버 : 접속 가능 주소 관리 서버  - 서비스 인스턴스는 실행/종료 될 때 레지스트리로 등록/취소 요청 - 레지스트리는 주기적으로 인스턴스 생존확인 - 클라이언트는 레지스트리에게 접속할 인스턴스 정보를 획득 |
* 낙관적 동시성 제어(optimistic concurrency control)
 : 사용자들이 같은 데이터를 동시에 수정하지 않을 것이라고 가정 읽은 시점에 Lock을 사용하지 않되, 수정 시에는 읽은 데이터가 다른 사용자에 의해 변경되었는지를 반드시 검사 |
쿠버네티스의 구성
| 클러스터 | 쿠버네티스로 관리되는 워커 노드와 마스터 노드의 모임. |
| 마스터 노드 |
클러스터를 제어하고 관리하는 중앙 처리 장치. API 서버, 스케줄러, 컨트롤 매니저, etcd 등으로 구성 |
| 워커 노드 |
실제 애플리케이션 및 서비스를 실행하는 노드 파드 관리, 네트워크, 스토리지, 컨테이너 런타임 등 포함 |
| 파드 | 하나 이상의 컨테이너를 묶어서 관리하는 쿠버네티스의 배포 가능한 최소 단위 공유된 네트워크 및 스토리지를 가질 수 있음 |
| 서비스 | 파드 집합에 대한 네트워크 엔드포인트를 정의하고 로드 밸런싱을 제공하는 추상화 단일 접근 지점을 제공해 파드를 논리적으로 그룹화함. |
| 볼륨 | 컨테이너에서 사용될 데이터 저장을 위한 디스크 영역. 파드 내의 컨테이너가 공유하거나 연결할 수 있음. |
| 네임 스페이스 |
리소스를 논리적으로 분리하는 가상 클러스터. 팀 또는 프로젝트 간에 클러스터를 공유 시 사용. |
| 컨트롤러 | 파드 및 기타 객체를 관리하고 유지하는 추상화 계층 ReplicaSet, Deployment, StatefulSet 등 |
- 쿠버네티스 클러스터
> 쿠버네티스 컨테이너를 배포하기 위한 서버 집합
- 마스터 노드
: 클러스터 상태 저장 및 관리
> etcd : 클러스터에 배포된 앱의 실행/상태 정보를 Key-Value로 저장
> API 서버 : 클러스터 상태 조회, 변경을 위한 인터페이스 제공
> Scheduler : 노드를 선택하기 위한 스케쥴링
> Contoller Managers : 사용자가 요청한 컨테이너 개수가 맞는지 확인
- 워커 노드
: 컨테이너 실행 담당
> kubelet, Container Runrime 등으로 구성
> kube-proxy : 트래픽을 pod로 전달하기 위함
API 전달 과정
1) kubectl을 통해 요청을 보낸다.
2) kubectl이 요청을 HTTP 요청으로 변환하여 마스터 노드에 전달
3) API서버는 받은 요청을 etcd에 저장한다.
4) Controller Managers를 통해 이벤트를 읽어들인다.
5) (생성 요청이라 가정) API 서버는 pod 생성 정보를 etcd에 저장
6) Scheduler는 node에 생성되지 않은 해당 pod를 읽어들임
7) Scheduler는 pod가 필요한 사양에 따라 최적의 node를 선택
8) scheduler는 해당 노드 정보를 pod에 담아 API 서버로 반환
9) API 서버는 해당 노드 정보를 etcd에 기입하며 노드 할당을 완성함
10) 해당 워커 노드는 kubelet을 통해 pod 생성 요청을 인지함
11) kublet은 docker에게 컨테이너 생성을 위임함
12) kublet은 지속적으로 컨테이너들의 헬스체크를 담당함
- 컨테이너 상태가 나빠지면 etcd에 기록하고 재시작 또한 담당함
Kube-proxy와 iptable을 이용한 통신
- 각 노드에는 kube-porxy가 존재
- 리소스 엔드포인트 추가
1) API 서버에서 리소스 엔드포인트 추가 명령 전송
2) kube-proxy는 자신의 iptables에 해당 규칙을 설정/갱신함
- 클라이언트의 요청
1) worker노드 1의 10.76.1.52에 요청됨
2) 이 친구는 목적지가 10.80.13.74임
3) iptables에서 해당 목적지로 갈 수 있는 방법이 2개 임을 확인
4) 1번 목적지가 택해져 woker 노드 2번으로 도착하게 됨
실습
GCP Kubernetes Engine 기반 클러스터 생성 및 접근
1) 클러스터 생성
- Autopilot모드가 아닌 표준 모드 이용
- 옵션 변경 없이 이름만 my-cluster로 설정
2) 준비 확인
- 준비가 완료되면 화면처럼 체크표시 활성화
3) 클러스터 접속
- 우측 …버튼을 통해 연결 후, CLOUD SHELL에서 실행 선택
4) kube config 설정
- 접속 시 이용한 '연결'창의 명령줄 액세스 코드 복사
- 실행한 Cloud Shell에 붙여넣기
5) 설정 정보 확인
| cat ~/.kube/config |
> 출력
 |
 |
+ Google Cloud CLI 설치
: https://cloud.google.com/sdk/docs/install-sdk?hl=ko
+ Kubectl 설치
: https://kubernetes.io/ko/docs/tasks/tools/#kubectl
+ gke-gcloud-auth-plugin 설치
: https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke?hl=en
Kubernetes Object
: 애플리케이션 배포/운영을 위한 모든 k8s 리소스
- 오브젝트가 될 수 있는 요소
| 어떤 앱을 | Pod |
| 얼마나 | Replica Set |
| 어디에 | Node Namespace |
| 어떻게 배포 | Deployment |
| 어떻게 로드밸런싱 | Service, Endpoint |
Pod
: 노드에서 컨테이너를 정의하기 위한 가장 기본적인 단위
- 특징
> Pod 생성 시, 유일한 IP 할당
> Pod 내부 컨테이너 간에서는 localhost로 통신
> Pod 내부에서는 네트워크와 볼륨 등의 자원 공유
> Pod IP는 클러스터 내부에서만 접근 가능
- 장점
> 명령어 하나로 원하는 Pod 생성
| # 복제본 생성 kubectl scale deployment "애플리케이션이름" --replicas=3 # pod 정보 확인 kubectl get pod |
* 클러스터 외부 트래픽을 받으려면 Service or Ingress 오브젝트 필요
Pod의 단위 배포 및 스케일 아웃
| Pod와 Container의 관계가 1:1인가 1:n인가? |
Q1. 컨테이너들의 라이프사이클이 같은가?
> A가 종료되었을 때 B의 존재가 의미없다면 하나의 Pod로 묶자
> ex. 서버와 로그 시스템
Q2. 스케일링 요구사항이 같은가?
> A는 10개 필요한데, B는 1개가 필요하다면 엮을 필요가 없다
> ex. 웹 서버 vs 데이터베이스, 트래픽이 많은 vs 그렇지 않은
Q3. 인프라 활용도가 더 높아지는 방향인가?
> 노드 리소스 사용 상태 등을 고려해서 설계하자
Pod 배포 과정
1. 사용자로부터 Pod 배포 요청을 수락한다
2. 요청 받은 수만큼 Pod Replica를 생성한다 (Pod desired state == current state)
3. Pod을 배포할 적절한 노드를 선택한다 (nodeSelector)
4. 5에게 이미지 다운로드를 명령하고 Pod 실행을 준비한다. Pod 상태를 업데이트한다.
5. 이미지를 다운로드하고 컨테이너를 실행한다
Pod 오브젝트 표현법 : 기본 설정
- apiVersion : k8s 인터페이스 버전
- kind : 생성 오브젝트의 타입
- metadata : 오브젝트의 기본 식별 정보
- spec : 배포 노드, 컨테이너 정보, 배포 장소 등
Pod 오브젝트 표현법 : spec.nodeSelector - 노드 선택
- 의미 : pod에 포함될 컨테이너로 리스트 형태 선언도 가능
Pod 오브젝트 표현법 : spec.containers - 환경변수 env
- 의미 : 컨테이너에 설정할 환경변수
* $(환경변수_이름) 으로 선언한 다른 환경변수를 참조 할 수 있다.
Pod 오브젝트 표현법 : spec.containers - 볼륨 마운트
- 의미 : 컨테이너에 대한 볼륨 마운트
- 다른 컨테이너도 같은 볼륨 마운트 가능함을 보임
Pod 오브젝트 표현법 : spec.containers - 볼륨 목록
- 의미 : 사용 가능한 볼륨의 목록을 작성
* hostPath는 볼륨 타입으로 아래 링크에서 다양한 타입 확인 가능
* https://kubernetes.io/docs/concepts/storage/volumes/
Pod의 한계점
- Pod가 종료되었거나 하면 자가 치유 능력이 없음
> 노드 이상으로 종료 시 끝
=> 사용자 선언 수만큼 Pod 유지하는 ReplicaSet 오브젝트 도입
- Pod IP는 외부에서 접근 불가
=> Pod집합을 외부 클러스터로 노출하기 위한 Service오브젝트 도입
'기술 단어장 > Kubernetes' 카테고리의 다른 글
| [k8s] Pod에 대한 통합 엔드포인트, Service (0) | 2024.03.04 |
|---|---|
| [k8s] Deployment를 이용한 배포전략 (0) | 2024.03.04 |
| [k8s] Pod의 안정적인 실행, ReplicaSet (0) | 2024.03.03 |
| [k8s] Pod 환경 변수 설정 및 Pod간 통신 구현 (0) | 2024.02.29 |
| [네트워크] 쿠버네티스(Kubernetes)는 어디에 사용할까? (0) | 2021.07.08 |
댓글