4. 왜 필요한가?
운영환경에서의 컨테이너 관리
가동 중지 시간이 없는지 확인
다운되면 다른 컨테이너 다시 시작
분산 시스템을 탄력적으로 실행
애플리케이션의 확장과 장애 조치
배포 패턴 제공 (카나리아 배포)
5. 기능
1. 서비스 디스커버리와 로드 밸런싱
2. 스토리지 오케스트레이션
3. 자동화된 롤아웃과 롤백
4. 자동화된 빈 패킹(bin packing)
5. 자동화된 복구(self-healing)
6. 시크릿과 구성 관리
6. 쿠버네티스는 PaaS가 아니다.
1. 지원하는 애플리케이션의 유형을 제약하지 않는다.
2. 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
3. 애플리케이션 레벨의 서비스를 제공하지 않는다. (MQ, Spark, mysql…)
4. 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다.
5. 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하
지 않는다.
9. 컨테이너
리소스 한계 정의 불가능
다른 애플리케이션 성능 저하
VM간에 애플리케이션 격리
일정 수준의 보안성
리소스 효율적 활용
격리 속성을 완화
애플리케이션간 OS 공유
자체 파일시스템, CPU, 메모리, 프로세스 공간 존재
기존 인프라와의 종속성 없음=>어디에나 이식가능
이미지 불변성 => CI/CD에 적합. 빠르게 롤백가능
개발시점에 이미지 생성하므로, 개발과 운영이 동일
자원격리. App 성능 예측가능.
11. 파드
쿠버네티스 애플리케이션의 기본 실행 단위
배포 단위
쿠버네티스의 애플리케이션 단일 인스턴스
내부 컨테이너는 1개 (90% 이상이 1개)
내부 컨테이너 2개이상 (백그라운드 용도 프로세스)
수평적 스케일아웃
인스턴스를 여러 개의 파드로 복제
파드를 직접적으로 사용가능. 그러나 컨트롤러를 사용하여 파드를
관리하는 것이 쿠버네티스에서 훨씬 더 보편적
12. 서비스
ClusterIP : 기본 서비스 타입. 쿠버네티스 클러스터 내부에서 사용가능.
클러스터 내부포드에서 이 ClusterIP를 이용해서 이 서비스에 연결된 포
드에 접속 가능. 클러스터 외부에서 이용불가.
NodePort : 각 노드에 지정된 포트를 할당하는 방식. 노드의 포트를 사
용하기 때문에 클러스터 내부 뿐만 아니라 클러스터 외부에서도 접근이
가능. 클러스터외부에서 클러스터내부의 포드로 접근할때 사용하는 가
장 간단한 방법.
LoadBalancer : AWS, GCP 같은 클라우드 서비스를 사용할때 사용가능
한 옵션. 클라우드 로드밸런서와 연결해서 클러스터 외부에서 접근이
가능.
ExternalName : 서비스를 externalName의 값이랑 매치. 클러스터 내부
에서 외부로 접근할때 주로 사용. 이 서비스로 접근하면 설정해둔
CNAME값으로 연결되서 클러스터 외부로 접근할 수 있습니다.
13. 레플리카셋
언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장
동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인
실패하거나 삭제되거나 종료되는 경우 자동으로 교체
프로세스 감시자(supervisor)와 유사
개별 프로세스를 감시하는 대신 여러 노드에서 여러 파드를 감시
디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께
파드에 대한 선언적 업데이트를 제공하는 상위 개념
예전의 레플리케이션 컨트롤러는 이제 사용하지 않으며, 그 대신
레플리카셋을 구성하는 디플로이먼트를 사용해야 함.
실행
$ kubectl apply -f sample.yaml
sample.yaml
14. 디플로이먼트
파드와 레플리카셋에 대한 선언적 업데이트를 제공
디플로이먼트 - 의도하는 상태 설명
디플로이먼트 컨트롤러 - 현재 상태에서 의도하는 상태로 비율을
조정하며 변경
실행
$ kubectl apply -f sample.yaml
15. 디플로이먼트 업데이트
롤아웃
디플로이먼트의 파드 템플릿(즉, .spec.template)이 변
경된 경우에만 디플로이먼트의 롤아웃이 트리거
(trigger)
디플로이먼트는 업데이트되는 동안 일정한 수의 파드
만 중단되도록 보장. 기본적으로 적어도 의도한 파드
수의 75% 이상이 동작하도록 보장 (최대 25% 불가).
디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는
파드의 수를 제한. 기본적으로, 의도한 파드의 수 기준
최대 125%까지만 추가 파드가 동작할 수 있도록 제한
먼저 새로운 파드를 생성한 다음 이전 파드를 삭제하고,
새로운 파드를 만듦.
16. 디플로이먼트 롤백
먼저 롤아웃 기록을 확인
현재 버전에서 이전 버전으로 롤백
실행 예
$ kubectl rollout undo deployment.v1.apps/nginx-deployment
17. 데몬셋
모든 노드가 동일한 파드를 실행하도록 함.
노드가 클러스터에 추가되면 데몬셋의 파드도 추가됨.
노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로
수집됨.
데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리됨.
대표적인 용도
각 노드에서 클러스터 스토리지 데몬의 실행
모든 노드에서 로그 수집 데몬의 실행
모든 노드에서 모니터링 데몬의 실행
18. 레이블
키와 값의 쌍
오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요
코어 시스템에 직접적인 의미 없음.
$ kubectl get pods -l environment=production,tier=frontend
21. 퍼시스턴트 저장소
볼륨은 볼륨을 묶는 포드와 동일한 수명을 갖음
포드가 존재하지 않으면 볼륨도 존재하지 않음
많은 유형의 볼륨을 지원하며 포드는 여러 볼륨을 동시에 사용가능
종류
1. 임시디스크
1. 로컬 디스크 또는 램
2. 클라우드 볼륨
1. AWS EBS
2. Google Cloud 퍼시스턴스 디스크
3. NFS
1. 기존 NFS (네트워크 파일 시스템) 를 포드에 연결
2. 포드제거시 NFS볼륨의 내용은 유지되고 마운트 해제
25. 사용법
Kubectl (큐브컨트롤) 명령어
노드확인
kubectl get nodes
POD 실행
kubectl run web01 --image nginx --port=80
Pod 확인
kubectl get pods
개수 증가(Scale out)
kubectl scale deploy web01 --replicas=2
포트오픈
kubectl expose deployment web01
--type=NodePort
서비스 확인
kubectl get services
POD 삭제
kubectl delete deployment web01
서비스 삭제
kubectl delete service web01