Kubernetes를 사용하면서 궁금했던 개념 정리Docker
Docker
Docker는 다양한 어플리케이션, 프로그램, 실행환경등을 컨테이너로 추상화할 수 있게 해주고 배포 및 관리를 단순하게 해준다.
장점
Host OS위에 바로 Docker를 올리기에 커널을 공유, io가 빠름
scale out, 이식성이 뛰어남
단점
vm과는 다르게 완벽한 격리는 아님, 멀티OS 불가
Docker 사용시 궁금했던 것
1) Layer 저장방식
image pull할때 전체를 다운받지 않고 로컬에 layer1,2,3이 있다면 그 위에 올라가는 layer4만 pull 받음
2) cmd, entrypoint 명령어 차이
default 지정 여부
cmd로 정의하면 컨테이너가 실행할때 cmd에 정의한 명령어를 실행할수도 있고 컨테이너 실행시 파라미터로 인자값을 주면 그 값으로 대체하여 실행할 수도 있음
즉 default값을 설정하고 나중에 바꿀 수 있음
변경해서 실행하는 명령어를 정의할때 사용
entrypoint로 정의하면 컨테이너 실행시 인자값을 줘도 안바뀜
변경하면 안되는 명령어를 정의할때 사용
kubernetes
컨테이너화된 어플리케이션의 배포, 확장, 관리를 자동화하는 시스템
Kubernetes를 쓰는 이유?
어플리케이션 환경을 탄력적으로 실행할 수 있게 된다.
컨테이너의 장애 대응과 확장에 용이하다.
기능
서비스 디스커버리와 로드 밸런싱
storage 오케스트레이션(로컬, 공용 클라우드와 같이 원하는 저장소 탑재 가능)
자동화된 롤백,롤아웃(원하는 형태로 설정하고 변경 가능)
자동화된 빈 패킹(각 컨테이너가 필요하는 cpu,mem 제공)
자동화된 복구(실패한 컨테이너 재시작 및 교체 가능)
시크릿 구성관리(암호, OAuth, 토큰, ssh키 같은 정보를 저장하고 관리)
노드 구성
1) 마스터 노드
클러스터에 관한 전반적인 결정을 수행하고 이벤트를 감지하고 반응하는 역할
-
kube-apiserver
모든 요청을 처리하는 역할 -
kub-controller-manager
다양한 컨트롤러(복제/배포/상태)를 관리 -
kube-scheduler
상황에 맞게 적절한 worker node를 선택 -
etcd
클러스터내의 데이터를 담는 저장소
2) 워커 노드
어플리케이션을 동작하고 유지시키는 역할
-
pod
컨테이너화된 어플리케이션 그룹 -
kublet
Node에 할당된 Pod의 상태를 체크하고 관리 -
kube-proxy
Pod로 연결되는 네트워크를 관리
참고: https://tech.ktcloud.com/70?category=465864
Kubernetes 컴포넌트 개념
인그레스
클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음
가장 많이 사용되는건 쿠버네티스에서 제공하는 ingress-nginx이다.
시크릿(secret)
비밀번호, OAuth 토큰, ssh 키 같은 민감한 정보들을 저장하는 용도로 사용한다.
이런 정보들은 컨테이너 안에 저장해 두지 않고 별도로 보관해 두었다가 실제 Pod가 실행할때 설정을 통해서 컨테이너에 제공해 준다.
인증
TLS인증과 ServiceAccount 인증이 있음
k8s는 TLS 인증이 적용되어있기에 TLS 인증시 서버와 client 둘다 인증서가 필요함
공인 인증 기관에서 발급받아서 사용하는데 openssl등의 오픈소스 라이브러리를 이용해서 직접 생성해서 사용할 수도 있음
이런 인증서를 사설 인증서라고 하고 공인기관에서 검수받지 않았기 때문에 브라우저에서는 위험한 인증서라고 표시됨
쿠버네티스에서 apiserver과 kubectl이 통신할때는 외부에 공개하는 서버가 아니라 굳이 공인기관에서 인증받은 인증서가 필요하지 않기 때문에 사설 인증서를 만들어서 사용하는 일이 많다.
이 때, 인증서가 공인기관의 인증서인지 검증하는 과정을 건너뛰는 옵션이 insecure-skip-tls-verify 옵션이다.
CNI 플러그인
Kubenet 플러그인: bridge와 host-local CNI 플러그인을 사용하여 기본 cbr0 구현한다.
네트워크 연결 : 노드(eth0) - NAT - 브릿지(cbr0) - pod(veth0)
kube-proxy
k8s 클러스터내부에 별도의 가상 네트워크를 설정하고 관리
Pod에서 다른 Pod의 서비로 접속할때는 노드 IP나 Pod IP는 필요없고 서비스 IP로 접속하면 됨
서비스 IP로 접속하면 NAT영역에서 서비스로 라우팅해줌
NAT영역의 설정은 kube-proxy가 담당
kube-proxy는 apiserver가 변경되면 설정된 각 서비스에 해당되는 NAT 규칙을 업데이트 해줌
헤드리스 서비스(headless service)
서비스를 만들때 ClusterIP를 None으로 설정하면 Cluster IP가 없는 서비가 만들어진다.
이런 서비스를 헤드리스 서비스라고 한다.
로드밸런싱이 필요없거나 단일 서비스 IP가 필요없는 경우에 사용
데몬셋(daemonset)
클러스터 전체에 Pod를 띄울때 사용하는 컨트롤러
데몬셋을 이용해서 Pod를 실행하면 항상 그 Pod가 클러스터 전체 노드에 떠 있게 된다.
노드가 클러스터에서 빠졌을때는 그 노드에 있던 Pod는 그대로 사라지고 다른 곳으로 옮겨가서 실행되거나 하지는 않는다.
그렇기 때문에 데몬셋은 보통 로그수집기를 실행하거나 노드를 모니터링하는 모니터링용 데몬등 클러스터 전체에 항상 실행시켜 두어야 하는 pod를 실행하는데 사용한다.
kube-apiserver
쿠버네티스 클러스터의 api를 사용할수 있게 해주는 프로세스
클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할을 한다.
쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달된다.
kubelet
kubelet은 클러스터내의 모든 노드에서 실행되는 에이전트
Pod내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할을 한다.
kubelet은 PodSpecs라는 설정을 받아서 그 조건에 맞게 컨테이너를 실행하고 컨테이너가 정상정으로 실행되고 있는지 상태 체크를 한다.
Operator
Operator는 K8s 어플리케이션을 패키징, 배포, 관리하는 방법을 말한다.
Controller는 기본적으로 Custom Resource의 상태를 읽어 현재 상태와 비교해 CR에 정의된 상태로 클러스터의 싱크를 맞춰주는 역할을 한다.
CR(Custom Resource)+Controller를 같이 사용하는 패턴을 Operator 패턴이라고 한다.
Helm
K8s 패키지 관리를 도와준다.
흔히 패키지관리를 도와주는 npm, pip와 비슷하다.
아키텍처는 client와 서버(tiller)로 구성되어 있었지만 v3부터 tiller가 빠졌다.
-
Chart
k8s에 어플리케이션이 기동되기 위한 모든 리소스 정보가 있다.
deployment, secret, service -
Repository
차트 저장소로 차트를 모아두고 공유하는 장소이다.
-
Release
K8s에서 구동되는 차트 인스턴스이다.
Helm Chart를 Repository에서 검색해 새로운 Release를 생성
K8s에 배포를 편하게 하기위해 미리 템플릿을 만들어놓고 템플릿에 들어가는 값들을 chart로 작성해 Chart 값만 다르게하면서 배포하는 방식
다른 환경, 다르게 배포할 수 있게 해주는 도구, 운영이나 개발환경에서 배포등에 편하게 사용할 수 있다.
이미지 출처
참고
