ETCD
ETCD : 분산, 속도, 신뢰할 수 있으며 고가용성을 제공하는 분산 키-값 저장소입니다.
키값 저장소 : 정보를 문서나 페이지 형태로 보관합니다. 각 문서를 받고, 그 개인 데이터에 대한 모든 정보는 해당 파일에 저장됩니다.
Etcd 컨트롤 클라이언트는 etcd의 커맨드라인 클라이언트 입니다. 키값 쌍을 저장하고 회수할 수 있습니다. etcd에서 사용되는 Raft 합의 알고리즘은 분산 시스템에서 일관성과 안정성을 보장하기 위해 설계된 분산 일관성 알고리즘입니다. Raft 알고리즘은 리더와 팔로워, 후보자 세 가지 역할로 분리되어 있습니다. 각 노드는 이러한 역할 중 하나를 가지며, 시스템이 동작하는 동안 상태를 전환할 수 있습니다.
etcdctl은 etcd와 상호 작용하기 위한 CLI 도구입니다. etcdctl은 두 가지 API 버전인 버전 2와 버전 3을 사용하여 etcd 서버와 상호 작용할 수 있습니다. 기본적으로 버전 2를 사용하도록 설정되어 있습니다. 각 버전에는 다른 명령어 세트가 있습니다.
etcd 저장소는 클러스터에 관한 여러 정보를 저장합니다. 클러스터 내 어떤 변화가 있다면 etcd 서버가 업데이트 되어 이를 반영합니다.
kubeadm을 이용해 클러스터를 설정하면 kubeadm이 그 외 기타 서버를 배포하는데 kube ststem namespace에 있는 Pod를 말입니다. 쿠버네티스는 특정 디렉터리 구조에 데이터를 저장합니다. Registry 아래에 minions, pods, replicasets 등이죠.
- etcd를 고가용성으로 설정하기:
- etcd를 고가용성으로 설정하려면 여러 etcd 인스턴스를 클러스터로 그룹화해야 합니다. 이를 위해 보통 홀트 조인(HAProxy 등을 사용한 로드 밸런싱)과 같은 방식을 사용하여 여러 etcd 인스턴스를 로드 밸런서로 노출시킵니다.
- etcd 클러스터는 각각의 노드에 etcd를 실행하고, 이들을 서로 연결하여 클러스터를 형성합니다. etcd는 Raft 알고리즘을 사용하여 고가용성을 제공합니다.
- 클러스터를 설정하고 초기화하는 단계에서 각 etcd 노드를 정확하게 구성해야 하며, 네트워크 설정 및 보안 설정도 적절히 구성해야 합니다.
- kubeadm을 사용하여 Kubernetes 클러스터 구축:
- kubeadm은 Kubernetes 클러스터를 구축하기 위한 공식 도구 중 하나로, 단순하고 쉽게 Kubernetes를 설정할 수 있도록 지원합니다.
- kubeadm을 사용하면 마스터 노드와 워커 노드를 설정하고 초기화할 수 있습니다. 이 과정에서 kubeadm은 etcd와 API 서버 등 Kubernetes 컴포넌트를 자동으로 설치하고 구성합니다.
- etcd를 고가용성으로 설정한 경우, kubeadm을 사용하여 Kubernetes를 설치할 때 이를 고려하여 etcd 클러스터의 주소 및 인증 정보를 kubeadm 구성 파일에 제공해야 합니다.
Kube API Server
kubectl 명령을 실행하면 kube-apiserver에 도착합니다. kube-apiserver가 요청을 먼저 인증하고, 유효성을 검사합니다. 이후 ETCD Cluster에서 데이터를 검색하고 업데이트 하는 일을 맡습니다. 직접 저장소와 상호작용하는 유일한 구성요소입니다. 다른 컴포넌트인 스케줄러, Controller-manager, kubelet 같은 것은 API 서버를 이용해 각 영역의 클러스터에서 업데이트를 수행합니다.
Kube Controller Manager
Master 내 각자 맡은 책임을 갖는 부서가 있는 것과 비슷합니다. Controller는 지속적으로 진행합니다. 시스템 내 다양한 컴포넌트들의 상태를 모니터링하거나 원하는 기능 상태로 만드는 역할을 합니다.
1. Node Controller - kube-apiserber를 통해 Node의 상태를 모니터링하고, 응용 프로그램이 계속 실행될 수 있도록 필요한 행동을 합니다.
2. Replication Controller - Replicasets가 원하는 수의 Pod가 항상 사용 가능하도록 모니터링 합니다. Pod가 죽으면 다른 Pod가 생깁니다.
위 1,2 말고도 굉장히 다양한 Controller가 존재하는데 이는 Kube Controller Manager 내에 존재합니다.
Kube Scheduler
스케줄러는 Pod가 어떤 노드로 갈지 특정한 기준에 의해 결정하는 것을 유일하게 책임집니다. Pod를 Node에 두는 것이 아니라, 그것의 일은 kubelet이 합니다. kubelet은 배의 선장이라고 했고, 배에 Pod를 생성합니다.
Kubelet
kubelet은 k8s cluster에 Node를 등록합니다. container나 pod를 Node에 load 하라고 지시를 받았을 때 kubelet은 container runtime engine에 요청합니다. 만약 Docker라면 요청된 이미지를 Docker로부터 pull 합니다. 그리고 인스턴스로 실행합니다. kubelet은 그러면 계속 pod의 상태를 모니터링하고 동시에 kube-apiserver에 보고합니다. 위와 다르게 수동으로 Worker Node에 설치되어 있습니다.
Kube proxy
k8s cluster 내에서 모든 Pod는 서로 닿을 수 있습니다. pod network는 가상 내부 네트워크에 모든 pod가 연결되어 클러스터 내 모든 노드에 걸쳐있습니다. 이 네트워크를 통해 서로 통신할 수 있습니다. kube proxy는 k8s 클러스터의 각 노드에서 실행되는 프로세스 입니다. 새 서비스가 생성될 때마다 각 노드에 적절한 규칙을 만들어 그 서비스로 트래픽을 전달합니다.
예를 들어보자. A pod -> B pod로 통신을 원한다. A pod는 서비스의 주소로 접근을 시도할 것이지만, 이는 가상 IP이기에 상위 네트워크로 옮겨지더라도 도착지의 위치를 찾지 못한다. 이를 도와주는 것이 kube-proxy이다. 모든 노드에 하나씩 실행되며, 각각 실행되는 노드에게 서비스의 IP로 향하는 데이터를 어떤 pod로 보내야할지 알려준다. userspace, IPVS, iptabels 모드가 있다.
Pods With Yaml
k8s의 .yml은 4개의 상위 필드를 가집니다. apiVersion, kind, metadata, spec. 필수되어지기 때문에 항상 포함해야 합니다.
apiVersion은 객체를 생성할 때 사용하는 k8s API 버전입니다. kind는 만들려고 하는 객체의 유형을 작성합니다. metatdata는 객체의 name, labels 같은 정보를 작성할 수 있습니다. 위 apiVersion, kind는 String 형태입니다.
metadata는 dictiontary의 form을 가집니다. metadata 내 name은 해당 객체의 이름을 지정할 때 사용하며 String 값입니다. Label은 metadata 내 사전이고, 키와 값을 가질 수 있습니다.
spec은 사전입니다. Pod 생성을 예로 containers는 List/Array입니다. 이유는 여러개의 컨테이너가 Pod안에 있을 수 있기 때문입니다. 그리고 첫번째 항목을 가리키는 것은 "-"을 뜻합니다.