1. Kubernetes 개요
Application 배포 방법
Traditional Deployment
- Application 구성
- Application Binary (bin)
- Application이 의존하는 Library (lib)
- Application을 배포 받아 실행 가능한 여러 요소를 개별 computer에 배포
Virtualized Deployment
Hypervisor 기반의 가상 머신을 통해 Application 생성 및 배포
Container Deployment
application이 격리된 프로세스에서 동작할 수 있도록 하는 image 배포 방식
Application Architecture
Application을 구성하는 방법
Monolithic Architecture
어플리케이션 전체가 하나의 운영체제 프로세스로 실행
- 하나의 객체로 개발, 배포, 관리
- 하나의 변경사항을 적용하기 위해 전체를 다시 빌드/테스트/배포
- application 확장 어려움
Microservice Architecture
각 micro service는 독립적인 프로세스로 실행,
API (Application Programming Interface)로 또 다른 micro service와 통신
- 새로 추가되거나 변경사항이 발생하면 해당 서비스만 빠르게 빌드/테스트/배포 가능
- resource가 더 필요한 서비스만 별도로 확장 가능
Microservice Architecture의 구성요소는 독립적인 방식으로 개발
단점
각각의 기능을 micro serive 단위로 나눠서 개발/테스트/개발
=> 구성 요소의 수 증가, 각각의 micro service 간의 종속성 관리 어려움
Application 개발 과정
- 개발 : 개발 환경
- 테스트 : 테스트 환경
- 통합 -> monolithic architecture
- 배포 : 운영 환경
- 유지보수
개발, 프로덕션 환경에 대한 일관된 환경 구성
개발/배포하는 구성 요소와 상관없이 개발자/운영자가 해결해야 하는 문제는
application 실행 환경이 매번 다른 환경이라는 점
↑ 위 문제를 줄이기 위해 프로덕션 환경에서는 application 개발과 프로덕션이 정확히 동일한 환경에서 되도록 구성
개발자와 운영자 간 다른 생각
개발자
새로운 기능을 만들고 사용자 경험 향상 중시
운영자
개발자에게 우선순위가 낮은 시스템 보안, 사용률과 같은 측면 중시
Kubernetes 필요성
개발자는 기능 개발을, 시스템 관리자 (운영자)는 보안/사용률과 같은 측면에 중요도 부여
Kubernetes를 사용하면
- 개발자는 특정 인프라 관련 서비스를 application에 구현하지 않아도 되고 실제 기능 개발에 집중
- 시스템 관리자 (운영자)는 Kubernetes가 application 재배치하고 조합
-> 리소스를 훨씬 효율적으로 관리 가능, 장애 발생해도 자동으로 처리 - Kubernetes는 container화된 application을 쉽게 배포 관리 가능한 orchestration 도구
마스터 노드 (Control Plane)
전체 Kubuernetes 시스템을 제어/관리하는 Kubernetes control plane 실행
워커 노드
실제 배포되는 container application이 실행됨
클러스터
마스터 노드와 워커 노드의 집합
2. Kubernetes 구성 요소
Kubernetes (k8s)
container화된 application을 쉽게 배포/관리 가능한 orchestration 도구 (참고)
- 구글이 내부적으로 사용하던 container 관리 도구를 오픈소스화하여 공개
- 현재는 CNCF 재단에서 관리 운영
Kubernetes 구성 요소
마스터 노드 (Control Plane) - 서버 역할
클러스터 제어가 주목적 : 워커 노드 관리
구성 요소
- kube-apiserver
- 사용자 상호 작용 수행
- Kubernetes 제어 명령 수신
- API 명령 수신
- kube-scheduler
- 새로운 POD (container) 생성 감지
- 실행시킬 워커 노드 선택
- etcd
- 클러스터의 모든 데이터 보관
- 고가용성을 보장하는 Key-Value 저장소
- 어떤 노드가 존재하고 클러스터에 어떤 리소스가 있는지 등의 정보 저장
- kube-controller-manager
- deployment 같은 리소스 컨트롤 관리
- API 서버를 통해 클러스터 공유 상태 감지
- 현재 상태를 원하는 상태로 이행하는 컨트롤 루프 관리
- cloud-controller-manager
- public cloud와 연동하여 로드 밸런서나 디스크 볼륨 등의 자원 관리
워커 노드
컨테이너화된 application 실행
구성 요소
- kubelet
- 각 노드에서 실행되는 에이전트
- container run-time 관리 및 상태 모니터링
- POD에서 container가 확실하게 동작하도록 관리
- kube-proxy
- 각 노드에서 실행되는 네트워크 프록시
- Service 개념 구현부
- 서로 다른 노드에 있는 POD 간 통신이나 POD와 인터넷 간 트래픽 라우팅
- container run-time
- container 제어 기능 (실행-중지-삭제)
- CRI (Container Run-time Initiative) : 공통 container run-time 규격
Kubernetes를 사용하기 위한 기본 환경 구성은 클러스터 생성 의미, 클러스터는 여러개 생성 가능
3. Kubernetes 환경 구성
Kubernetes 환경 구성 == Kubernetes 클러스터 구성
Kubernetes 환경 구성 요소
Kubernetes 환경 구성 필수 요소
- CRI (Container Run-time Initiative)
- Kubeadm
- Kubectl
- Kubelet
- CNI (Container Network Interface)
마스터 노드
- CRI (Container Run-time Initiative)
- Kubedam
- Kubectl
- Kubelet
- CNI (Container Network Interface)
워커 노드
- CRI (Container Run-time Initiative)
- Kubeadm
- Kubectl
- Kubelet
Kubernetes 환경 구성 종류
KubeAdm
Kubernetes에서 제공하는 클러스터 생성/관리 도구
KubeSpray
Kubernetes 클러스터를 배포하는 오픈 소스 프로젝트
- 다양한 형식으로 Kubernetes 클러스터 구성 가능
- 온프레미스에서 상용 서비스 클러스터 운영시 유용
- 다양한 CNI 제공
MiniKube
- 로컬 시스템에 설치 가능
- 설치가 간단하면서 Kubernetes가 제공하는 기능 활용 가능
- 개발 도구와 MiniKube 연계 가능
- 단일 노드(워커 노드) 형태로 동작
- 노드를 가상화 형태로 생성 => Docker, VirtualBox 등의 가상화 도구가 추가로 필요
- 학습/개발용으로 많이 사용
Docker Desktop
Linux / Windows / MacOS
Docker Desktop의 설정에서 Kubernetes를 활성화하면 MiniKube와 유사하게 Kubernetes 사용 가능
k3s
경량 Kubernetes 배포판
- CNCF에서 육성하는 프로젝트, Rancher Labs에서 제작
- k3s 실행 파일을 통해 서버와 에이전트만 구동하면 Kubernetes 각 구성 요소가 간편하게 설치 및 Kubernetes 클러스터 구성됨
- 마스터 노드의 etcd를 파일형 DBMS sqlite 사용
- IoT, 학습용 초소형 컴퓨터 (라즈베리 파이 등)에도 사용 가능
rancher
Kubernetes 클러스터 뿐만 아니라 운영에 필요한 모니터링, 보안 관련 기능을 쉽게 설치 가능
- rancher의 관리 도구를 사용해서 새로운 Kubernetes 클러스터를 쉽게 생성하고 여러 클러스터를 한 곳에서 관리
- 대규모 시스템 관리를 고려하여 많은 도구 제공
CRI (Container Run-time Initiative)
Docker 기반 Kubernetes 구조
Kubelet이 명령을 받으면 Docker runtime을 통해 container 생성/삭제 생명주기 관리 구조
Docker 이외 다양한 container 기술 적용 Kubernetes 구조
Docker 이외 다양한 container 기술이 생기면서 Kuberneters에서 다양한 container runtime을 지원하게 되었고, 그 때마다 Kubelet의 코드를 수정하는 문제 발생
Kubelet 수정 없이 다양한 container 지원 Kubernetes 구조
CRI (Container Runtime Interface)
: Kubelet 수정 없이 다양한 container runtime을 지원하기 위한 통일된 인터페이스 스펙
- container runtime이 CRI 스펙에 맞춰 구현되면 Kubelet 수정 없이 새로운 runtime을 플러그인 구조로 추가하여 사용가능한 구조 제공
OCI (Open Conatiner Initiative)
- 새로운 container runtime이 생길 때마다 CRI를 수정하는 문제 발생
-> container runtime을 표준화하고자 하는 결과물 - OCI 스펙에 맞춰서 구현된 container runtime은 별도의 CRI 구현 없이 OCI 구현체 관리 가능
- OCI 스펙에 따른 container runtime 관리하는 CRI 컴포넌트를 CRI-O라는 컴포넌트로 구현
- OCI 스펙을 준수한다면 CRI-O를 통해서 Kubelet으로부터 명령 받을 수 있음
- 참고
CNI (Container Network Interface)
CNCF 프로젝트, container 간의 네트워킹 제어 가능한 플러그인 방식으로 만든 표준
-
다양한 형태의 container runtime과 orchestration 사이의 네트워크 계층 구현 방식
-
Kubernetes에서는 POD (container) 간 통신을 위해서 CNI 사용
-
Calico, Weavenet, AWS CNI 등 다양한 종류
KubeAdm을 이용한 Kubernetes 환경 구성
-
Master node (Control plane), Worker node에 해당하는 서버 생성 (준비)
: Kubernetes 설치 가능 최소 사양 이상으로 구성 (필수 포트 번호 확인해서 포트 개방)
스왑의 비활성화 : kubelet이 제대로 작동하게 하려면 반드시 스왑 사용 X 설정sudo swapoff -a : swap 기능 off
echo 0 > /proc/sys/vm/swappiness : 커널 속성의 swap disable, root 사용자로 전환 후 수행
sed -e '/swap/ s/^#*/#/' -i /etc/fstab : swap을 하는 파일시스템을 찾아 삭제 -
Master node (Control plane), Worker node에 container runtime 환경 구성
: Docker 설치 -
kubeAdm, kubectl, kubelet 설치
- kubeadm : 클러스터를 부트스트랩하는 명령
- kubectl : 클러스터와 통신하기 위한 CLI, 클
- kubelet : 클러스터의 모든 머신에서 실행되는 Pod와 Container 시작 등의 작업을 수행하는 컴포넌트
-
Master node / worker node 구성
-
CNI 구성
-
Kubernetes 환경 구성 확인
