푸잉이의 기술블로그
[Day1] Certified Kubernetes Administrator (CKA) with Practice Tests 본문
[Day1] Certified Kubernetes Administrator (CKA) with Practice Tests
data고수 2023. 1. 3. 02:59Kubernetes란?
- 컨테이너 운영을 자동화하기 위한 컨테이너 오케스트레이션 도구 (프레임 워크)
- 수많은 컨테이너를 협조적으로 연동시키기 위한 통합 시스템
Kubernetes Architecture
Kubernetes 목적
- 자동화된 방식으로 (컨테이너 형태) 애플리케이션을 hosting (서버 컴퓨터의 전체 또는 일정 공간을 이용할 수 있도록 임대해주는 서비스)하여 애플리케이션의 많은 인스턴스를 쉽게 배포할 수 있도록 하는 것.
Kubernetes cluster
- 클러스터 (Cluster)란 컨테이너 형태의 애플리케이션을 호스팅하는 물리/가상 환경의 노드들로 이루어진 집합
- 쿠버네티스 내 가장 큰 단위, 가상 서버들이 속한 클라우드
노드 (Node)
- 클러스터 내 가상 서버, 즉 컴퓨팅 엔진 단위
- 마스터 노드 : 전체 쿠버네티스 시스템을 관리 및 통제하는 쿠버네티스 컨트롤 플레인 관장
마스터 노드가 죽으면 클러스터를 관리할 노드가 없어져, 일반적으로 3개 정도의 마스터 노드를 띄워 관리
(예시: 올바른 선박 식별, 정보 저장, 컨테이너 위치 모니터링, 어디로 갈지 계획, 노드와 컨테이너 모니터링
-> Control playing components)
- 워커 노드: 배포하고자 하는 애플리케이션의 실제 실행을 수행
(예시: 화물선 선박)
*컨테이너 (Container): 애플리케이션을 포장하고 실행하는 좋은 방법
*포드 (Pod): 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 컴퓨팅 단위, 하나 이상의 컨테이너 그룹
<배포>
kubectl run nginx --image nginx
pod를 생성하여 docker 컨테이너를 배포함
<kubectl get pods>
클러스터 pod의 수 및 상태 확인
*크기 단위: 클러스터>노드>파드>컨테이너
*YAML
apiVersion, kind, metadata, spec 최상위 수준, Root 수준 속성으로 필수 입력란
*apiVersion : 개체를 생성하는데 사용하는 쿠버네티스 API
*Kind:만들고자 하는 객체의 종류
*Metadata: name(문자열), labels(dict) 등의 데이터
*spec: 만들려는 객체에 따라 추가 정보를 제공하는 곳
ETCD Cluster (Master node)
- Key-Value 형태로 저장하는 DB
<전통적인 데이터베이스>
-> 새로운 정보를 추가하면 테이블 전체가 영향 받고, 빈 셀도 많아짐
<Key-Value Store>
-> 파일을 변경해도 다른 파일에 영향을 미치지 않음
-> 다른 정보를 추가할 수 있음
-> 데이터가 복잡해지면 일반적으로 JSON, YANO와 같은 데이터 형식을 사용하는 걸 추천
-> Kubernetes는 기반 스토리지(backing storage)로 etcd를 사용하고 있음
-> 모든 데이터가 etcd에 보관
EX.) 클러스터에 어떤 노드가 몇 개나 있고 어떤 파드가 어떤 노드에서 동작하고 있는지가 etcd에 기록됨. 만약 동작 중인 클러스터의 etcd 데이터베이스가 유실된다면 컨테이너뿐만 아니라 클러스터가 사용하는 모든 리소스가 미아가 되어 버립니다.
<Install ETCD>
1. Binary 다운 2. 압축 풀기 3. 실행
*Binary 파일이란?
: 이진 파일 형식의 문자열이 포함되어 있으며 컴퓨터가 사용하는 이진 텍스트 파일
1. Github 릴리스 페이지에서 운영 체제에 맞는 관련 바이너리를 다운로드
*Curl 명령어란?
: Cleint url 로 프로토콜들을 이용해 URL로 데이터를 전송하여 서버에 데이터를 보내거나 가져올 때 사용하기 위한 명령줄 도구 및 라이브러리
2. 압축 풀기
3. 실행
<Operate ETCD>
ETCD 실행 -> 디폴트 값 2379 포트에서 대기하던 서비스가 시작
- Key-Value pair 저장 (데이터베이스에 해당 정보 저장)
- 명령어: ./etcdctl set key1 value1
- 저장된 데이터 검색
- 명령어: ./etcdctl get key1
- 옵션 검색
- 명령어: ./etcdctl
<ETCD Data store>
Nodes, PODs, Configs, Secrets, Accounts, Roles, Bindings, Others
클러스터를 어떻게 설정하느냐에 따라 ETCD 다르게 배포
1. Scratch로부터 배포
2. Qadium 툴을 사용하여 배포
-> Advertise-client-urls 는 2379 포트가 디폴트인 ETCD가 대기하고 있는 주소
URL은 KubeAPI서버에서 ETCD서버에 접근하려고 할 때 구성되어 있어야함
클러스터 설정 (KubeADM)
:KUBE 시스템 네임스페이스 안의 POD로 배포
명령어: Kubectl get pods -n kube-system
<Explore ETCD>
POD 내에서 ETCD Control utility를 사용하여 DB 탐색 가능
특정 디렉토리 구조로 데이터 저장
Root (Registry)
- minions, pods replicasets, deployments, roles, secrets
<ETCD in High Availability Environment>
- 클러스터 안에 여러 Master node가 있음
- 분산된 여러 ETCD 인스턴스를 갖고 있음
Kube-Scheduler (Master node)
- 예시: 크레인 (선박의 크기, 용량, 선박에 있는 컨테이너 수, 배의 목적지, 실을 수 있는 컨테이너 유형 고려)
- 기타 정책이나 제약조건, 허용조건, 노드 우선 순위 규칙을 참고하여 컨테이너를 배치할 올바른 노드를 선택
- 노드에서 pod 스케쥴링 담당, pod가 어디로 가는지만 결정 (어떤 Pod가 어떤 node로 가야하는지 결정- 실제론 pod를 노드에 배치 x-> kubelet 선장이 배치)
<예시: CPI:10 요구>
스케쥴러 작동방법: 2단계
1. Filter Node pod에 가장 적합한 노드를 식별하여 pod에 맞지 않는/충분하지 않은 node) 필터링 시도
2. 노드의 순위 매김 (노드의 프리한 리소스 양을 계산하고, pod를 free 리소스가 더 많은 노드에 배치)
<kube-scheduler-manual 설치>
1. kubernetes release 페이지: kube-scheduler 바이너리 다운로드
2. Extract
3. 서비스로 실행 (scheduler configuration file 지정)
<Kube-scheduler options-Kubeadm >
Kubeadmin 툴로 셋업 -> kube-system namespace에 POD로 배포
kubectl get pods -n kube-system
cat/etc/kubernetes/manifests/kube-scheduler.yaml
Controller-Manager (Master node)
- 컨테이너가 훼손된 경우 새 컨테이너를 사용할 수 있는지 확인 등 다양한 부서들이 있음.
- 지속적으로 배의 상태에 대해 모니터링
- 상황을 개선하기 위해 필요한 조치
- 전체 시스템이 의도된 기능과 상태로 작동하게 하는 프로세스
- 단일 프로세스 패키징 되어있음
Node-Controller
- 노드를 관리, 새 노드를 클러스터에 온보딩하는 일을 담당 or 노드를 사용할 수 없거나 파괴되는 상황 다룸
- Kube API sever를 통해 애플리케이션이 계속 실행될 수 있도록 노드의 상태를 모니터링하고 필요한 조치를 취하는 것
- 5초마다 노드의 상태 테스트
- 노드의 심장박동이 멈추면 노드는 접근할 수 없는 것으로 표시 -> 바로 표시하지는 않고 40초 동안 holding
- 노드가 접근할 수 없는 것으로 푷시되면 회복할 수 있는 시간 5분 제공
- 5분 안에 회복되지 않으면 노드에 할당된 pod 제거
Replication-Controller
- 항상 원하는 수의 컨테이너가 replication 그룹에서 실행 중이라는 것을 보장함.
- Replica sets의 상태를 모니터링
- Pod가 죽으면 또 다른 pod를 만들어낸다.
Other Controllers
- Job-Controller, PV-Protection-controller, endpoint-controller, namespace controller 등 다양한 컨트롤러를 통해 구현됨
- 컨테이너들은 쿠버네티스 뒤에서 작동하는 뇌의 역할을 맡음
<Kube-controller-manager 설치 >
Kubernetes release 페이지에서
1. kube-control-manager 다운로드 받기
2. Extract
3. 서비스 실행
<Kube-controller-manager-Kubeadm >
Kubeadmin 툴로 셋업 -> kube-system namespace에 POD로 배포
<Kube-Controller-manager options Kubeadm>
Pod definition file에서 옵션 확인 가능
cat/etc/kubernetes/manifests/kube-controller-manager.yaml
<Kube-controller-manager options -Manual>
Kubeadmin으로 셋업하지 않았다면, cat/etc/systemd/system/kube-controller-manager.service
Kube-APIserver (Master node)
- 기본 관리 컴포넌트 (Primary management component)
- 클러스터 내의 모든 작업을 오케스트레이션
- 클러스터에서 관리 작업을 수행하기 위해 외부 사용자가 사용하는 쿠버네티스 API를 노출함
- 워커노드가 서버와 통신
DNS 서비스 네트워킹 솔루션은 컨테이너 형태로 배포 가능
컨테이너를 실행할 수 있는 소프트웨어 필요
-> 컨테이너 런타임 엔진
가장 많이 사용하는 엔진: 도커
다른 종류: ContainerD, Rocket
<순서>
Kubectl 명렁어 실행 -> Kubectl 유틸리티는 Kube-APIServer에 접근->요청 인증 및 검증 -> ETCD 클러스터로부터 데이터 받아서 요청한 정보와 함께 응답
반드시 Kubectl 명렁어 사용하지 않아도 됨 -> post request 를 보내서 API 직접 호출
<Kubeadm>
kubeadmin 툴로 셋팅 ->Master node에 있는 Kube-system namespace의 pod로 kubeadmin-apiserver를 배포
<Kube-APIserver options Kubeadm>
Pod definition file에서 옵션 확인 가능
cat/etc/kubernetes/manifests/kube-apiserver.yaml
<Kube-APIserver options -Manual>
Kubeadmin으로 셋업하지 않았다면, cat/etc/systemd/system/kube-apiserver.service
kube-apiserver 서비스를 확인하여 옵션 검사
Kubelet (Woker node)
- 배의 선장, 컨테이너 관리
- 선장의 선박이 그룹 참여에 관심이 있다는 것을 Master node와 연락함
- 선박에 적재되는 컨테이너에 대한 정보 수신
- Master node에게 이 배의 상태와 선박의 컨테이너 상태에 대한 보고서를 다시 보냄
- 클러스터의 각 노드에서 실행되는 에이전트
Kube-proxy (Woker node)
- 워커 노드에서
- 워커 노드에 있는 컨테이너들이 서로 접근할 수 있도록 하는 필수 규칙이 워커 노드에 있는지 확인
