네트워크교육 30~31일차 (2022.02.15~16)

용어정리

도커

1. 도커 엔진이 설치된 단일 시스템에서 다수의 컨테이너를 구동하는 방식으로 쉽게 구성

2. 단일 시스템 만으로는 확보 할 수 있는 자원이 한정

3. 구동되고 있는 엔진에 장애 발생 시, 컨테이너를 사용하는 모든 서비스가 중지 될 수 있음.

오케스트레이션

1. 다수의 시스템과 애플리케이션을 쉽게 설정, 유지 관리 할 수 있는 방식

2. 도커 자체적으로 '도커 스웜'을 통해서 오케스트레이션을 지원하고 있음

3. 도커 스웜은 도커와 유사하고 쉬운 동작방식이지만, 기능이 비교적 단순, 세세한 조정 어려움

쿠버네티스

1. 여러 컨테이너 오케스트레이션 도구 중 현재 가장 주목 받고 있는 도구

2. 구글에 의해 개발된 컨테이너 오케스트레이션 도구

3. 쿠버네티스는 기본적으로 도커 플랫폼 사용

쿠버네티스 아키텍쳐

1. 쿠버네티스 클러스터는 여러 시스템의 연결로 구성

2. 마스터와 노드 구성요소로 분류

3. 필요에 따라 추가요소가 있을 수 있음.

마스터

1. 쿠버네티스 클러스터를 구성하기 위한 핵심 요소들의 모음

2. 노드에 작업을 분배, 스케줄링 등 전반적인 결정을 수행, 대응이 필요한 클러스터 이벤트 감지하고 대응

3. API서버, etcd, 스케줄러, 쿠버네티스 컨트롤러 관리자 등 여러가지의 기능을 함.

API 서버

1. API(Application Programming Interface) 는
서로 다르게 구성되어 있는 기능들이 데이터를주고 받기 위한 방식

2. 쿠버네티스의 구성요소들은 마스터의 API 서버와 메세지를 주고 받게 되고 API서버가 허브역할을 수행하여 요청을 수신하고 명령을 전달

etcd

1. 쿠버네티스 클러스터의 모든 정보 데이터를 저장하는 저장소

2. 데이터 저장시 'key-value' 형태로 데이터를 저장

3. 데이터 백업에 대하여 반드시 고려할 필요가 있음

노드

1. 쿠버네티스의 컨테이너가 동작하는 런타임 환경을 제공하며, 동작중인 파드를 유지하는 기능을 담당

2. 노드의 역할은 큐블릿, 프록시, 컨테이너 런타임 이 있다.

큐블릿

1. 쿠버네티스 클러스터의 각 노드에서 실행되는 에이전트로,
마스터로부터 제공받는 pod의 구성 정보, 노드가 수행하여야 할 작업을 전달받아서
컨테이너가 확실하게 동작하도록 보장하는 것

프록시

1. 클러스터의 각 노드에서 실행되는 네트워크 프록시로 '서비스'를 구현하기 위한 기능

2. 클러스터 내부 간 통신이나, 외부->내부로 전달되는 통신 등 호스트 레벨의 네트워크 규칙을 구성,
외부연결을 pod에 포워딩하며 서비스의 추상화를 제공

메니페스트

1. 쿠버네티스는 클러스터의 상태를 나타내기 위해 오브젝트 개체를 정의하여 사용

2. 오브젝트를 생성할 때는 기본정보, 상세 스펙을 정확하게 제시 해야함

3. 필수 요구 필드 값 :

apiVersion = 오브젝트를 생성하기 위한 API 버전 지정
kind = 오브젝트의 종류를 명시
metadata = name, label, namespace 등 기본적인 정보를 기술
spec = 오브젝터의 세부 상태를 정의

실습 코드

레플리케이션 컨트롤러(pod) 생성

kubectl run mytest-app --image=c1t1d0s7/myweb --port=8080 --generator=run/v1 image-pull-policy=Nerver

서비스 접속

curl xxx.xxx.xxx.xxx:8080

pod 확인

kuberctl get pods
kubectl get pods -o wide

레플리케이션 컨트롤러 확인

kubectl get replicationcontrollers
kubectl delete pods mytest-app-xxxxx
kubectl get pods
kubectl get pods -o wide

서비스 생성

kubectl expose replicationcontroller mytest-app --type=LoadBalancer --name mytest-app-svc
kubectl get services
kubectl get pods -o wide

서비스 접근

curl 192.168.56.xx:XXXXX

파드 스케일링

kubectl scale replicationcontroller mytest-app --replicas=3
kubectl get pods -o wide
curl 192.168.xx.xx:XXXXX 실행 시 로드밸런싱 확인

kubectl delete pods mytest-app-xxxx
kubectl get pods
kubectl get replicatoncontrollers
kubectl delete replicationcontrollers mytest-app

모든 오브젝트 확인

kubectl get all

서비스 삭제

kubectl delete services mytest-app-svc
kubectl get all

yml 파일 이용

오브젝트 생성

kubectl create -f xxxxx.yml

실행중인 pod 정의 확인

kubectl get pods 파드명 -o yaml
kubectl get pods 파드명 -o json

자세한 정보확인

kubectl describe pods 파드명

로그 확인

kubectl logs 파드명

파드 파트 포워딩

kubectl port-forward 파드명 호스트포트:파드포트

레이블

레이블은 쿠버네티스 클러스터의 모든 오브젝트(파드 포함)에 키/값 쌍으로 리소스를 식별하고 속성을 지정하는 데 사용

오브젝트 개수가 많아진다면 오브젝트를 식별하는데 매우 어려울 수 있으며, 오브젝트의 적절한 레이블을 부여하여 성격을 정의하고 검색을 용이하게 할 수 있음

레이블은 사용자에게는 중요하지만, 쿠버네티스 클러스터에 직접적인 의미는 없음


레이블의 예:
∙ release: stable / canary / A / B
∙ environment: dev / qa / production
∙ tier: frontend / backend / cache / database
∙ partition: customerA / customerB
∙ track: daily / weekly
∙ app: webapp / middleware

레이블 구문:
키는 "접두사(옵션)/이름" 형식으로 사용 가능하며, 영문자, 숫자, 대시(-), 언더스코어(_), 점(.)이 올 수 있음
이름은 최대 63자를 넘지 못함

레이블 셀렉터
레이블 셀렉터는 오브젝트에 부여되어 있는 레이블을 식별하고 검색할 수 있음
- 검색 방법은 두 가지
∙ 특정 키가 있는/없는 레이블 포함
∙ 특정 키와 값이 있는/없는 레이블 포함
레이블 셀렉터를 이용하여는 검색하는 방법은 두 가지를 제공


- 일치성 기준(Equality-based) 요건
∙ =
∙ ==
∙ != 


- 집합성 기준(Set-based) 요건
∙ in
∙ notin 

label이 포함된 파드 생성 yml파일

label 확인

kubectl get 오브젝트 --show-label

기존 pod에 label 생성

kubectl label 기존 파드 key=value

기존 pod label 수정

kubectl label 기존 파드 key=value --overwrite

어노테이션

어노테이션을 포함한 yml 파일

어노테이션(Annotation)은 주석이라고도 하며 오브젝트에 비-식별 메타데이터를 지정할 수 있음 
레이블과 비슷하게 키/값을 가지고 있지만, 레이블은 레이블 셀렉터를 이용하여 식별 및 검색을 할 수 있지만, 어노테이션은 어노테이션 셀렉터를 가지고 있지 않음
즉, 비-식별 메타데이터로 추가적인 정보를 제공하기 위함
어노테이션은 쿠버네티스 클러스터에서 API 서버 및 다른 애플리케이션이 어노테이션에 지정된 키/값을 참조 가능


어노테이션 사용 예:
∙ 선언적 구성 정보
∙ 타임스탬프, 릴리즈 ID, git 브랜치, PR 번호, 이미지 해시, 레지스트리 주소
∙ 로깅, 모니터링, 분석, 감사 정보
∙ 디버깅 정보
∙ 다른 요소와의 관련 개체 URL 지정
∙ 책임자, 관리자 정보

명령어를 이용한 어노테이션

kubectl annotate 파드명 key="값"

확인

kubectl get pods 파드명 -o yaml

네임 스페이스 (namespace)

네임스페이스 생성 yml

특정 네임스페이스 지정 파드 생성

네임스페이스
오브젝트를 논리적으로 분리할 수 있는 논리적 파티션

기본 네임스페이스 : 

∙ default : 기본 네임스페이스
∙ kube-node-lease : 
- 쿠버네티스 노드의 가용성을 체크하기 위한 네임스페이스
- 해당 네임스페이스에는 하트비트를 위한 리스(Leases) 오브젝트가 있음
- 쿠버네티스 1.14 이상

∙ kube-public
- 모든 사용자(인증받지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있음
- 관례적으로 만들어져 있지만 아무 리소스도 없고, 꼭 사용해야 하는 것은 아님

∙ kube-system
- 쿠버네티스 클러스터의 핵심 리소스 배치

추가적인 네임스페이스:
∙ ingress-nginx
- 쿠버네티스 인그레스(Ingress) 리소스를 위한 Nginx 인그레스 컨트롤러 배치
∙ rook-ceph
- Rook Ceph 스토리지 관련 리소스 배치 

네임스페이스 확인

kubectl get namespaces

특정 네임스페이스의 파드 확인

kubectl get pods -n 네임스페이스명

모든 파드 확인

kubectl get pods --all-namespaces

리소스 삭제

오브젝트 이름 지정 삭제

kubectl delete pods 파드명

오브젝트의 정의파일을 사용하여 삭제

kubectl delete -f xxxx.yml

오브젝트 레이블을 사용하여 삭제

kubectl delete pods -l tier=frontend

오브젝트 상태 모니터링

kubectl get 오브젝트 --watch

or

watch -n1 kubectl get 오브젝트

pod의 단계

컨테이너의 상태

컨테이너의 재 시작 정책

컨트롤러

1. 쿠버네티스에서 어플리케이션을 구동하기 위해서는 pod를 생성하여야 함

2. 쿠버네티스는 컨테이너 가상화의 특징을 활용, 유연하고 확정성 있는 서비스를 구성할 수 있도록 오브젝트를 제공

3. 'A 파드를 3개 만들어라 가 아닌 3개를 유지하라' 방식

레플리케이션 컨트롤러 생성

레플리케이션 컨트롤러 확인

kubectl get replicationcontrollers

파드 확인

kubectl get pods --show-labels

kubectl describe replicationcontrollers testapp-rc

kubectl delete pods testapp-rc-xxxxxxx

kubectl get pods --show-labels

레이블 변경

kubectl label pods testapp-rc-xxxxxx env=dev

kubectl get pods --show-labels

kubectl label pods testapp-rc-xxxxxx app=test  --overwrite

kubectl get pods --show-labels

레플리카셋

쿠버네티스 초기 파드의 복제본을 생성하고, 
파드의 개수를 유지하는 기능을 제공하는 컨트롤러로 
'레플리케이션 컨트롤러'를 사용했음.
지금은 레플리케이션 컨트롤러 대신에 레플리카셋 컨트롤러를 사용하기 시작했음.

- 레플리카셋과 레플리케이션 컨트롤러의 비교

레플라카셋의 기본 목적은 레플리케이션 컨트롤러와 같지만, 
레플리카셋은 레이블 셀렉터의 "집합성 기준" 레이블 셀렉터를 지원    
레플리케이션 컨트롤러는 "일치성 기준" 레이블 셀렉터만 지원    
"일치성 기준" 레이블 셀렉터는 "키=값" 모두 일치해야 하지만,
"집합성 기준" 레이블 셀렉터는 "키=값" 모두 일치하거나, "키" 만 일치하는 것도 지원

● 레플리케이션 컨트롤러: 일치성 기준 레이블 셀렉터 지원

● 레플리카셋: 일치성 및 집합성 기준 레이블 셀렉터 지원

- 레플리카셋 컨트롤러 구성
레플리카셋은 apps API 그룹에 속하며 v1 버전을 사용

kubectl api-resources
kubectl api-versions  

apiVersion은 apps/v1를 사용하며 생성할 종류는 ReplicaSet이다. 
또한 
레플리케이션 컨트롤러에서는 레이블 셀렉터 항목에 레이블을 직접 지정했지만,

레플리카셋은 matchLabels 및 matchExpressions 필드로 레이블을 선택

.spec.selector.matchLabels: 일치성 기준 레이블 셀렉터 지정
.spec.selector.matchExpressions: 집합성 기준 레이블 셀렉터 지정

atchLabels는 레플리케이션 컨트롤러와 같이 특정 레이블의 키=값을 매칭
기능상 완전하게 똑같이 작동

확인  kubectl get replicasets.apps

레이블 매칭 확장 연산자

● In          : 레이블의 키가 존재하며, 값이 대상 중 하나와 일치함
● NotIn       : 레이블의 키가 존재하며, 값이 대상 모두와 불일치
● Exists      : 레이블의 키가 존재함 (값은 무관)
● DoesNotExist: 레이블의 키가 존재하지 않아야 함

Exists와 DoesNotExist는 레이블의 키값만 매칭
즉, values 항목을 설정하지 않는다.

레플리카셋 생성

kubepctl create -f testapp-rs-exp.yml

레플리카셋 확인

kubectl get replicasets.apps -o wide

kubectl get pods --show-labels

레플리카셋 삭제

kubectl delete replicasets.apps 컨트롤러명

데몬 셋

데몬셋(DaemonSet)은 노드 레이블과 매칭이 되는 모든 노드 또는 노드 레이블이 없다면 
모든 노드에 파드를 하나씩의 배치하는 컨트롤러 
기능은 레플리카셋과 비슷하지만, 복제본을 지정하지 않음
노드가 추가되면 자동으로 컨트롤러는 하나의 파드를 배치하게 되고,
노드가 제거되면 삭제된 파드를 다른 노드에 배치되지 않음

이는 복제본을 제공하는 컨트롤러가 아니기 때문

데몬셋 생성

데몬셋 오브젝트의 API 버전 역시 apps 그룹의 v1 버전을 사용

데몬셋 확인

kubectl get daemonsets.apps

오브젝트 정의에 노드셀렉터로 	node=development 레이블을 선택하도록 정의하였기
때문에 
노드 레이블과 매칭되는 노드가 없음, 아무 파드를 생성하지 않음

노드 레이블 확인

kubectl get nodes --show-labels

노드 레이블 설정

kubectl label nodes kube-node1 node=development

kubectl get nodes kube-node1 --show-labels

데몬셋 확인

kubectl get daemonsets.apps

kubectl get pods

노드 레이블 키 제거

kubectl label nodes kube-node1 node-

kubectl get nodes kube-node1 --show-labels

kubectl get daemonsets.apps

kubectl get pods

데몬셋 삭제

kubectl delete -f testapp-ds.yml