쿠버네티스
인프런 - 쉽게 시작하는 쿠버네티스(v1.20) 수강 중
쿠버네티스란?
도커와 같은 컨테이너 관리용 오케스트레이션으로 가장 빠르게 발전하는 사실상 표준(De facto)
Kubernetes는 k8s로 표현하기도 함
구글에서 사용하던 Borg 시스템을 CNCF 재단에 기부해 CNCF가 관리하고 있다
쿠버네티스 필요성
- 도커의 등장으로 이미지화와 컨테이너를 통해 관리가 매우 간편해짐
- 하지만 컨테이너가 늘어나게 된다면 여전히 하나하나 관리하는 것은 어려움
- 로드밸런서로 관리가 가능하지만 자동 처리가 필요
- 쿠버네티스같은 컨테이너 오케스트레이션을 통해 자동화가 가능
컨테이너 오케스트레이션 특징
컨테이너 오케스트레이션이란 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
- 클러스터
- 관리가 필요한 노드들이 늘어나면 클러스터 단위로 관리
- 하나하나 ssh로 접속하는 것은 너무 어렵기 때문에 마스터 서버를 두고 자동 관리하도록 함
- 클러스트 내 노드들끼리 네트워크 연결하여 통신에 문제가 없도록 함
- 수 천개 수 만개의 노드가 있더라도 부하 없이 잘 작동하도록 필요
- 상태 관리
- 특별한 직접적인 조치가 없더라도 상태를 자동으로 맞춰 줌
- ex) replicas를 2에서 3으로 늘려주면 자동으로 컨테이너가 3개 띄움
- 배포 관리
- 스케줄링을 통해 부하 조정
- ex) App을 실행 시킬 때 여유가 있는 서버에서 실행
- 배포 버전관리
- 노드 하나하나가 아닌 클러스터 단위로 자동 Rollout, Rollback
- 서비스 등록 및 조회
- 서비스 하나 하나 등록하는 것이 아니라 자동으로 등록 해주고 자동으로 설정 변경, 프로세스 재시작 가능
- 볼륨 스토리지
- 스토리지 연결을 설정으로 자동화 가능
쿠버네티스 마스터
etcd
- 모든 상태와 데이터 저장
- Key-Value 형태 데이터 저장
- 분산 시스템 구성
API 서버
- 상태를 바꾸거나 조회
- etcd와 유일하게 통신
- REST API 형태
- 권한 체크 및 요청 차단
Scheduler
- 새로 생성된 파드 감지 및 실행 노드 선택
- 노드 현재 상태와 파드 요구사항 체크
Controller
- 끊임없이 상태 체크
- 원하는 상태 유지
- 하나의 프로세스로 실행
예시
조회 흐름
- 컨트롤러가 API 서버에 정보 조회
- API 서버는 컨트롤러가 해당 리소스를 볼 수 있는지 정보 조회 권한 체크
- 권한이 있다면 API 서버가 etcd에 정보 조회
- 컨트롤러에 전달
기본 흐름
- etcd가 API 서버에 원하는 상태 변경됨을 알림
- API 서버가 컨트롤러에 원하는 상태 변경됨을 알림
- 컨트롤러가 현재 상태를 원하는 상태로 맞추기 위해 조치를 취해 리소스 변경
- 컨트롤러는 리소스 변경 사항을 API 서버에 전달
- API 서버는 컨트롤러가 정보 갱신 권한이 있는지 체크
- 권한이 있다면 API 서버는 etcd에 정보 갱신
쿠버네티스 노드
kubelet
- 각 노드에서 실행
- 파드 실행/중지
- 파드 상태 체크
proxy
- 네트워크 프록시와 부하 분산 역할
- iptables 또는 IPVS를 사용해 설정만 관리
쿠버네티스 배포 종류
- 관리형 쿠버네티스
- 사용자가 관리할 필요가 없고 필요한 어플리케이션을 올려 배포만 하면됨
- ex) aws, Azure, Google Cloud 등
- 설치형 쿠버네티스
- 설치를 할 수 있도록 패키지화한 것
- ex) Rancher, OpenShift
- 구성형 쿠버네티스
- 필요로 하는 환경 내에서 자유롭게 구성하고자 하거나 교육이 목적인 경우
- ex) kuberadm, kops, Kuberspray, KRIB 등
개발 환경
- Vagrant
- Virtual box
- Kubernetes
쿠버네티스 실행
- Vagrant 설정해서 한 번에 VM 실행
vagrant up - 마스터 노드에서 워커 노드 상태 확인
kubectl get nodes
애플리케이션 배포
- 마스터 노드에서 워커 노드로 애플리케이션을 설치할 수 있도록 명령
- 애플리케이션 배포 단위는
Pod(파드)
이미지 배포 및 설치
kubectl run nginx --image=nginx
파드 배포 상태 확인
kubectl get pod
배포한 파드 IP 확인
kubectl get pod -o wide
Pod(파드)란?
파드란 컨테이너의 집합을 의미한다. 하나의 일을 하기 위해 묶여진 컨테이너 집합이지만 대부분 단일 컨테이너가 하나의 파드로 구성된다.
배포한 파드 외부 접근
- 특별한 설정 없이 외부에서 배포한 파드에 접근할 수 없음
- 노드 포트에 접근하고 파드의 위치를 찾아가는 구조
파드 Expose
kubectl expose pod nginx --type=NodePort --port=80
서비스 확인
kubectl get service
결과: 30000 포트 확인
| NAME | TYPE | CLUSTER-IP | EXTERNAL-IP | PORT(S) | AGE |
|---|---|---|---|---|---|
| nginx | NodePort | <Cluster IP> | <none> | 80:30000/TCP | 4m32s |
- 노드 정보(IP) 확인
kubectl get nodes -o wide결과
| NAME | STATUS | ROLES | AGE | VERSION | INTERNAL-IP | EXTERNAL-IP | OS-IMAGE | KERNEL-VERSION | CONTAINER-RUNTIME | |
|---|---|---|---|---|---|---|---|---|---|---|
| w1-k8s | Ready | <none> | 2d17h | v1.20.2 | 192.168.1.101 | <none> | CentOS | Linux 7 (Core) | <kernerl v> | docker://19.3.14 |
외부 접속 - nginx 확인
http://192.168.1.101:30000/
하지만 파드가 하나이기 때문에 파드가 죽으면 서비스가 실행이 안됨
디플로이먼트를 통한 배포
디플로이먼트는 파드를 여러 개 가지고 있는 큰 단위
버전에 따라서 다르지만 파드만 kubectl run 명령어를 통해 디플로이먼트는 배포가 불가능하다
kubectl run
해당 명령어로 파드와 디플로이먼트 모두 배포가 가능하며 특히 kubectl apply는 파일을 통해 배포하는 방식이다
kubectl create
kubectl apply
디플로이먼트 생성
kubectl create deployment deploy-nginx --image=nginx
디플로이먼트가 delploy-nginx라는 이름의 이미지로 생성됨
생성된 결과 확인
kubectl get pods
파드 배포 수 늘리기
kubectl scale deployment deploy-nginx --replicas=3
노트포트는 노드 IP를 알아야하는데 로드밸런서는 고유 IP를 만들어 알려줄 수 있어 노드 IP와 포트를 열어주는 부담이 없다
로드밸런서 배포
kubectl expose deployment deploy-nginx --type=LoadBalancer --port=80
서비스가 생성이 되고 확인하면
kubectl get services
External-IP가 생성되어 접속이 가능하다
외부 접속
http://192.168.1.11/
배포 삭제
서비스 삭제
kubectl delete service nginx
디플로이먼트 삭제
kubectl delete deployment nginx
파드 삭제
kubectl delete pod nginx
[참조] 인프런 - 쉽게 시작하는 쿠버네티스(v1.20)
끝!