[CKA] Udemy 섹션 1 ~ 섹션 2.26

오늘 공부할 범위

Udemy 섹션 1 ~ 섹션 2.26

 

Kubernetes 기본 개념

k8s의 목적은 컨테이너 형태로 애플리케이션을 호스팅하는 것

선박에 비유한다면 컨테이너 형태로 애플리케이션을 호스팅하는 클라우드가 있고

k8s는 화물선과 관련이 있다 

컨테이너를 올리고 있는 선박 = worker node

선박의 정보를 저장하여 컨테이너를 어디에, 어떻게 실을지 모니터링하는 제어 선박 = master node 

 

master node 

etcd cluster : 에 대한 정보 

kube-scheduler : container 배치 정보 식별 (여러 제약 조건이나 정책 기반 ..)

controller manager 

    - node controller : 노드를 처리

    - replication controller : 원하는 수의 컨테이너가 실행되고 있는지 확인

kube-apiserver : 클러스터 내 모든 작업을 관리 / worker node의 상태를 지속적으로 보고 받아 노드 상태 모니터링

 

 

많은 작업물(=응용 프로그램) = 컨테이너 형태 

- master node에서 컨테이너 형태로 호스팅 될 수 있음

- 컨테이너와 호환되기 위한 장치 필요

= container runtime engine (= Docker)

 

worker node

kubelet - 선장이라고 보면 됨

    선박의 상태를 master node 로 전송하고 kube-api의 지시에 따라 노드에 컨테이너를 배포하거나 파괴

Kube proxy - worker node 끼리 통신 

---

ETCD 

ETCD란 ?

간단하고 안전하며 빠른 분산된 key-value store 

key-value store ??

보통 DB는 표 형태로 데이터를 저장함 (열-행으로 데이터를 표현)

key-value store는 key-value 형태로 데이터를 저장한다 키를 통해 데이터를 반환할 수 있고 키는 중복될 수 없다

따라서 빠른 읽고쓰기가 가능하다

 

ETCD in kubernetes

ETCD는 다음과 같은 정보를 저장한다 

- Nodes

- Pods

- Configs

- Secrets

- Accounts

- Roles

- Bindings

- Others ..

kubectl get을 통해 가져오는 모든 정보는 ETCD에서 가져온 것이다

모든 변경 작업(node 추가, pod 배포 등)또한 ETCD에 업데이트 되어야 작업이 완료 된 것이다

 

kubeadm으로 클러스터 설정하기

- pod 형태로 etcd배포 

ETCD 수신 기본 포트 = 2379

kube-api 서버가 etcd서버에 접속을 시도할때 설정해야 하는 URL

 

고가용성 환경에서는 master node가 여러개이다

etcd똰 분산되어 저장되는데 이때 etcd는 서로 정보를 알고있어야 한다 

따라서 etcd.service의 initial-cluster 옵션에서 다른 etcd 서비스의 인스턴스를 가져오도록 한다

Kube-API Server

kubectl 명령어 실행시 해당 명령은 실제로 kube api 서버로 간다

kube api 서버에서는 

Authenticcate User > Validate Request > Retrieve data > Update ETCD 순으로 작업이 진행된다

kube api 서버는 ETCD와 직접 상호작용하는 유일한 구성요소

sheduler, kube controller manager. kubelet등은 api 서버를 이용하여 클러스터에서 업데이트를 실행한다

 

Kube-controller manager

kube controller manager는 다양한 controller가 모인 사무실과 같다

시스템 내의 상태를 모니터링하고 원하는 기능을 수행할 수 있는 상태가 유지되도록하는 역할을 한다

ex. node controller - 노드의 상태를 모니터링하고 pod를 정상 노드에 프로비저닝

Replication controller - ReplacaSet의 복제본을 모니터링 하고 유지되도록 확인

이외 다양한 controller가 있음

 

Kube sheduler

어떤 pod가 어떤 node에 배치되면 좋을지 결정하는 역할

결정만 하고 실제 pod 배치 수행은 kubelet이 담당한다

scheduler는 특정 기준(사용자 정의 가능)에 따라 pod가 어떤 node에 배치되면 좋을지 결정한다

만약 pod가 특정 리소스 요구사항이 있다면 적합한 node에 배치

 

Kubelet

worker node의 선장역할 - master node(control plain)과 직접 소통

해당 선박에 대한 상태를 주기적으로 master node에 보고

pod를 로드하라는 명령이 내려지면

container runtime 요청 > docker등 엔진을 이용하여 pod 생성 > node, pod 상태 모니터링 후 kubeapi에 보고

 

kube-proxy

클러스터 내의 pod는 서로 다른 모든 pod에 연결할 수 있다

service를 배포한다면 pod는 서비스의 name을 이용하여 접근할 수 있는데 서비스는 실제 pod와 같은 컨테이너가 아니기 때문에 pod network에 포함될 수 없다 ( 가상 구성요소기 때문) --> pod와 service가 통신하기 위한 방법이 kube proxy

kube proxy는 클러스터내 각 노드에서 실행되는 스로세스

새로운 서비스를 찾는 역할 - 각 노드에 rule을 적용하여 해당 서비스에 대한 트래픽을 pod로 전달한다

 

pod

컨테이너를 worker node에 배치할때 pod형태로 캡슐화 하여 배치하게 된다

pod는 application 단위의 단일 인스턴스로, k8s의 가장 작은 단위 개체이다 

하나의 pod에는 하나이상의 컨테이너 존재하도록 하고, 만약 같은 역할을 하는 컨테이너를 추가하기 위해서는 pod를 만들도록 한다 (대부분 하나의 pod에 하나 container를 사용함)

같은 pod에 있는 여러 컨테이너들은 localhost로 통신이 가능하다 (port가 달라야함) / 동일한 저장공간도 쉽게 공유 가능

 

kubelet은 pod를 배포하는 방법이다

kubectl run nginx --image nginx

 

YAML을 이용한 pod 생성

yaml - pod를 만들기 위한 input 

필수로 포함되어야 하는 yaml root level 속성으로는 apiVersion , kind, metadata, spec이 있다

 

apiVersion : object를 생성하는데 사용되는 k8s api 버전

kind: 만들고자 하는 object의 종류

metadata: name, label, ,, object에 대한 데이터 - dic 형태로 적는다 (들여쓰기 주의)

spec: object 사양을 적음 - dic 형태로 적으며, 아래 containers라는 속성을 추가한다

containers는 list/array 형태로 적는다 --> '-'는 첫번째 item임을 의미

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80