-
쿠버네티스 ③ 기본 Architecture네트워크 & 인프라 2022. 10. 12. 23:39
이번에는 쿠버네티스의 기본 아키텍처에 대해 배워보자.
참고한 영상 👇🏼
- 모든 내용은 윗 영상을 캡쳐 및 정리한 내용입니다! 🙌
쿠버네티스 아키텍처
Master-Slave(Worker) 구조
- 1) 1개 노드 processes
- ex) 2 개의 어플리케이선 pod이 1개의 노드에 위치
- k8s 클러스터 안에 worker machine이 존재
- 각각의 노드가 여러개의 pod을 가지고 있음
- 2) 3개 노드 processes
- 3 processes는 개별의 workder 노드에 모두 설치되어야 함
- Worker Nodes : 실제 일을 수행
- Kubelet
- 모든 노드에서 실행되는 k8s에이전트
- 컨테이너, 노드와 상호작용
- pod을 운영하는 책임을 짐
- 컨테이너 내부(ex) cpu)와 함께 pod을 시작시킴
- service를 통해 소통
- Kubeproxy
- k8s의 네트워트 동작을 관리
- Kubernetes 서비스의 backend 구현
- endpoint 연결을 위한 iptables 구성
- nodePort로의 접근과 pod 연결을 구현(iptables 구성)
- 요청을 포워딩
- 만약 앱이 데이터 요청을 랜덤하게 다른 노드의 데이터베이스에 포워딩한다면 작동하지 않을 것
- 동작방식 (kube-proxy-mode)
- userspace
- 클라이언트의 서비스 요청을 iptables를 거쳐 kube-proxy가 받아서 연결
- kubernetes 초기 버전에 잠깐 사용
- iptables
- default kubernetes network mode
- kube-proxy는 service API 요청 시 iptables rule이 생성
- 클라이언트 연결은 kube-proxy가 받아서 iptables룰을 통해 연결
- IPVS
- 리눅스 커널이 지원하는 L4 로드밸런싱 기술을 이용
- 별도의 ipvs 지원 모듈을 설정한 후 적용 가능
- 지원 알고리즘
- Round Robin
- Least Connection
- Destination Hashing
- Source Hashing
- Shortest Expected Delay
- userspace
- k8s의 네트워트 동작을 관리
- Container runtime
- 컨테이너 실행 엔진
- docker, containerd, runc
- Kubelet
- 그렇다면, 어떻게 클러스터와 소통할 수 있을까? ⇒ 매니징 프로세스는 Master Node에 의해 수행
- pod 을 스케줄링
- 복제 pod을 모니터링
- pod 을 Re-schedule / Re-start
- 새로운 노드에 조인
Master processes
- 각각의 마스터 노드에서 4 processes 실행
- API server
- 사용자가 새로운 앱을 deploy하기 위해서는 API 통신해야 함
- cluster 게이트웨이
- 인증(보안)을 위한 게이트 keeper의 역할
- request → API Server → request 타당성 확인 → other processes 수행 → pod 에 전달
- ⇒ 클러스터로 진입하기 위한 입구가 1개이기 때문에 보안상 좋음
- Scheduler
- 새로운 pod에 어떤 노드를 스케줄링할 지 결정하는 역할
- 새로운 pod 생성→ API Server → Scheduler → pod을 위치시킴 → kubelet으로 전달
- Controller manager
- pod이 죽거나 중단된것을 탐지하고 가능한 빠르게 rescheduling하는 역할 (개수를 보장)
- 클러스터의 상태가 변화되는 것을 탐지
- pod 중단 → controller manager 탐지 → scheduler(리소스 계산) → kubelet → pods 재시작
- pod이 죽거나 중단된것을 탐지하고 가능한 빠르게 rescheduling하는 역할 (개수를 보장)
- etcd
- 클러스터의 뇌 역할
- 클러스터의 변화는 key-value 저장소에 저장됨
- 어떤 리소스가 사용 가능한지
- 클러스터의 상태가 변화되었는지
- 클러스터가 올바르게 실행되고 있는지
- 단, 어플리케이션 데이터는 etcd에 저장되지 않음
- API server
- 보통 여러개의 마스터 노드를 가짐
- api server 가 로드밸런스 됨
- etcd 는 모든 마스터 노드를 가로질러 저장소를 분배함
클러스터 셋업 예시
- 2 master : less resources
- 3 worker nodes : more resources
- 쿠버네티스를 이용하여 새로운 마스터 혹은 노드 서버를 추가 가능
- 1) 새로운 빈 서버를 획득
- 2) 마스터 혹은 워커 노드 프로레스를 모두 설치
- 3) 해당 서버를 클러스터에 추가
+ 계층별 추상화
- 모든 것이 쿠버네티스에 의해 배포 계층 아래 위치
- deployment ↓
- replicaSet을 관리
- replicaSet ↓
- pod의 복제본을 관리
- pod ↓
- 컨테이너를 추상화
- container
- deployment ↓
+ Addon
- 네트워크 애드온
- CNI - weave, calico, flaneld, kube-route …
- DNS 애드온
- core DNS
- 대시보드 애드온
- 컨테이너 자원 모니터링
- cAdvisor
- 클러스터 로깅
- 컨테이너 로그, k8s 운영 로그들을 수집해서 중앙화
- ELK(ElasticSearch, Logstash, Kibana), EFK(ElasticSearch, Fluentd, Kibana), DataDog
+ 멀티 마스터 쿠버네티스 클러스터 운영하기
- kubeadm
- 쿠버네티스에서 공식 제공하는 클러스터 생성 / 관리 도구
- kubespray
- 쿠버네티스 클러스터를 배포하는 오픈 소스 프로젝트
- 다양한 형식으로 쿠버네티스 클러스터 구성 가능
- 온프레미스에서 상용 서비스 클러스터 운영시 유용
- control plane(master node)
- 워커 노드들의 상태를 관리 및 제어
- Highly Available(HA) 클러스터 운영
- API는 loadbalancer를 통해 worker node에 노출
- 최소 3개의 중첩된 control plane을 구성 (5, 7개의 master nodes)
- worker node
- 도커 플랫폼을 통해 컨테이너를 동작하며 실제 서비스 제공
- 워커 노드의 모든 요청은 load balancer를 통해 전달되고 요청이 마스터 중 하나의 마스터에 균등하게 전달되고 변경된 정보는 etcd에 저장된 후 마스터들 끼리는 etcd를 동기화 하여 같은 정보를 가지도록 함
- 마스터 1개가 다운되어도 서비스는 계속해서 제공됨 → 고가용성 쿠버네티스 클러스터 구현
- 전체 구성
- 1) all system - runtime(Docker) install
- 2) control plane, worker node - kubeadm 설치 (+ kubectl, kubelet)
- 3) LB(load balancer) 구성
- 4) kubeadm을 이용한 HA 클러스터 구성
- 1) master1 : kubeadm init 명령으로 초기화 - LB 등록
- 2) master2, master3를 master1에 join ( 동기화 )
- 3) CNI(Container Network Interface) 설치
- 4) LB를 통해 worker node를 master와 join
- 5) 설치된 시스템 확인
'네트워크 & 인프라' 카테고리의 다른 글
쿠버네티스 ⑤ Namespace 와 Helm (0) 2022.10.12 쿠버네티스 ④ Minikube 와 Kubectl, K8s YAML configuration File (0) 2022.10.12 쿠버네티스 ② 메인 K8s component (2) (0) 2022.10.12 쿠버네티스 ① 메인 K8s component (1) (1) 2022.10.08 gRPC ③ gRPC + 스프링부트 프로젝트 구성해보기 (0) 2022.10.05