[AIVLE_AI] 가상화 클라우드 3일차

[AIVLE_AI] 가상화 클라우드 1일차

[AIVLE_AI] 가상화 클라우드 2일차

 

---

 

[ Objcet ] - Pod / NameSpace

Pod 개념	컨테이너를 담는 통 Kubernetes의 가장 작은, 최소 단위 하나 이상의 컨테이너 그룹 네트워크와 볼륨을 공유
Pod 구조 시각화		Pod 안에서 컨테이너 들은 네트워크 볼륨장치 (스토리지) 공유해서 사용 Pod가 삭제되면 Pod 구성원도 다 삭제
Pod 생성1 - Yaml 파일	kubectl create -f <yaml 파일명> ex) kubectl create -f pod.yaml	yaml 파일을 사용하여 Pod를 생성 하는 명령어 -f : file kubectl create -f pod.yaml : pod.yaml 기반으로 creat 하겠다.
Pod 생성2 - Kubectl 명령어	kubectl 명령으로 Pod를 생성하는 명령어 kubectl run <pod명> \ --image=<이미지명:버전> \ --port=<포트번호> ex) kubectl run pod \ --image=nginx:1.14.0 \ --port=80	kubectl 명령으로 Pod를 생성하는 명령 kubectl로 yaml파일 없이도 pod를 생성할 수 있다. : run을 활용해서
Yaml 파일 예시		들여쓰기와 대문자 조심하기! api 버전은 v1으로 yaml이 생성하고 관리할 오브젝트: Pod 메타 데이터는 nginx으로 구성 spec  파드 안에 컨테이너를 하나 만든다.  앞에 네임 스페이스 없으니까도커 허브에 있는 nginx 이미지 1.14.0버전으로 컨테이너를 만들기  80 포트 오픈 *80포트는 웹서버에 사용 nginx가 웹 서버이기 때문 => 웹 서버를 구성하는 pod 생성

 

같은 기능을 쓴다면 yaml -> 문법 고려, 대소문자 구분 등
짧게 빨리 쓴다면 kubectl 명령어

 

Namespace 개념	단일 클러스터 내 리소스 그룹 격리를 위한 오브젝트 사용자가 여러 팀으로 구성하는 경우, 프로젝트를 진행함에 있어 환경을 분리 해야 하는 경우 사용 (클러스터 = pc, 네임 스페이스 = 폴더로 생각하고 네임스페이스로 구분해서 PC 권한을 나눈거라 생각하면 됨)
Namespace 구조 시각화

---

 

[ Controller ]

Pod는 스스로 증감, 유지보수 및 복구 기능이 없다. 그렇기 때문에 Controller 기능이 필요하다.

 

Replica Set (복제품)

Replica Set 개념	Pod의 개수를 유지 yaml 을 작성할 때 replica 개수를 지정하면 그 개수에 따라 유지
ReplicaSet 생성 Yaml 파일		API 버전 v1 kind Replica Set metadata에 Replica Set  이름 rep1로 지정 spec에 Replica Set이 Pod 3개 유지 하도록 지 아래 생략된 부부에는 Pod의 속성이 들어감 최종적으로 Pod의 속성에 맞게 3개가 생
ReplicaSet 생성 Yaml 파일  구조 시각화		kubectl create -f rs.yaml

Replica Set 생성 및 에러

생성		pod의 속성이 template에 들어감 desired replicas(설계) = 3개 current replicas(실제) = 3개 current = desired 문제없음
에러		desired replicas(설계) = 3개 current replicas(실제) = 2개 current != desired 문제있음
오토힐링(에러 복구)		Pod 4 새로 생성 desired replicas(설계) = 3개 current replicas(실제) = 3개 current = desired 문제없음 사용자가 원하는 상태에 맞춰 유지

 

Template - Replica Set에서 Pod의 설계를 명세

Template 개념	파드를 생성하기 위한 명세 Deployment, ReplicaSet과 같은 Controller의 yaml 내용에 포함 Template에는 Pod 세부사항을 결정
Template Yaml 파일		Deployment 컨트롤러가 관리하는 Pod 의 라벨, 컨테이너 속성, 포트 등 명세

 

Deployment - Replicaset 관리

Deployment 개념	Deployment는 ReplicaSet을 관리하며 애플리케이션의 배포를 더욱 세밀하게 관리 초기 배포 이후에 버전 업데이트, 이전 버전으로 Rollback도 가능
Deployment 구조 시각화		v1 Deployment가 ReplicaSet을 관리해서 만 ReplicaSet이 Pod를 관리해서 Pod 배포 v2 업데이트 Deployment에게 명령 수 ReplicaSet v2 새로 생성 v2의 Pod 생해서 업데이트 및 롤백 ReplicaSet은 본인의 Version만 관리
Deployment 생성1 - Yaml	– kubectl create -f deployment.yaml – kubectl create -f <yaml 파일명>
Deployment 생성2 - kubectl	– kubectl create deployment dp \ --image=nginx:1.14.0 \ --replicas=3 – kubectl create deployment <이름> \ --image=<이미지명:버전> \ --replicas=<Pod 수>

 

Deployment 예시 - Create / Update

Deployment Create		Deployment를 만들면 ReplicaSet 이 만들어지고 Pod이 만들어져 개수 유지 Deployment에는 Pod의 갯수를 지정하기 위해 replicas Pod의 속성이 들어가는 template template안에 들어가는 Poddml image Deployment의 속성을 모두 받아서 ReplicaSet의 속성으로 가져옴 속성에 맞게 Pod 생성 Pod에는 image에 따라 Container 생성 및 배포
Deployment Update		Update를 하게되면 기존 Replicaset은 유지되고 Pod만 삭제 새로 Replicaset이 만들어지고 업데이트된 이미지 버전으로 Pod 생성 및 배포

 

Deployment Update - 2 가지 재배포 방법

Recreate	현재 운영중인 Pod들을 삭제하고, 업데이트 된 Pod들을 생성합니다. 이 방식은 Downtime 이 발생하기 때문에 실시간으로 사용해야 한다면 권장하는 방식은 아닙니다.
Rolling Update	먼저 업데이트 된 Pod를 하나 생성하고, 구버전의 Pod를 삭제하여, Downtime 없이 업데이트가 가능합니다.

 

Recreate Flow - Update Start / Delete Replicaset and New Replicaset

Recreate Flow 전체 시각화		구버전 Pod 삭제 Pod가 아무것도 없는 Downtime 잠깐 발생 새로운 Pod 생성 배포
Recreate Flow Update Start		v2
Recreate Flow Delete Replicaset and New Replicaset		기존 Replicaset을 0으로 줄이고 새로 Replicaset을 올림

 

Rolling Update Flow - Update Start / One by One / Complete

Rolling Update Flow 전체 시각화		업데이트 명령 수행시 신버전 Pod 한개 먼저 올림 신버전 Pod  한개 Running시 구버전 Pod 한개 삭제 신버전 Pod 하나 올림 신버전 Pod 하나 Running 구버전 Pod 하나 삭제 Downtime이 발생하지 않는다.
Rolling Update Update Start		ReplicaSet2를 먼저 만듦 새로운 Pod 하나 생성 Pod 갯수 총 3개
Rolling Update One by One		기존 ReplicaSet이 Pod를 2에서 1로 줄인다. 새로운 ReplicaSet은 Pod 새로 생성 Pod 갯수 총 3개
Rolling Update Complete		기존 ReplicaSet Pod 0개로 만듦 Pod 갯수 총 2개 *기존 ReplicaSet은 삭제되지 않고 남아있다. -> 백업 및 롤백용도로 활용

 

Deployment Rollback

Rollback 개념	Deployment는 이전버전의 ReplicaSet을 10개까지 저장 (revisionHistoryLimit 속성을 설정하면 개수를 변경 가능)  저장된 이전 버전의 ReplicaSet을 활용하여 Rollback
Update and Rollback 전체 시각화		최초 v1에서 v2 업데이트 후 v3 까지 업데이트 한 후  v2로 다시 롤백 각각의 Pod들은 지워지고  ReplicaSet은 남아있다.
Update and Rollback yaml		Type을 통해 업데이트 전략 선택 revisionHistoryLimit를 통해 남은 ReplicaSet을 몇 개 저장할지 설정할 수 있다.
Update and Rollback revisionhistorylimit		Recreate 방식으로 업데이트 ReplicaSet은 여분으로 한 개저장하는것 ReplicaSet v1로는 롤백 불가

 

* Rolling Update와 Recreate 방식의 차이점

	Rolling Update	Recreate
Downtime	발생하지 않는다.	발생한다.
메모리 가용성	상대적으로 높다	상대적으로 낮다
Downtime이 발생하지 않는 Rolling Update가 좋은가? -> 리소스 필요하기 때문에 꼭 그렇지는 않다. 환경, 상황에 맞게 활용

 

 

 

---

 Pod Scale - Deployment가 Pod 수 조절 때

Pod Scale 적용 시각화		RepliscaSet를 늘리거나 줄여준다.
Deployment로 생성된 Pod 수를  조정(Scale)하는 명령어	kubectl scale deployment/ dp --replicas=3 kubectl scale deployment/ --replicas=<조정할 Pod 수>
ReplicaSet으로 생성된 Pod 수를 조정(Scale)하는 명령어	kubectl scale rs/ rs --replicas=3 kubectl scale rs/ --replicas=<조정할 Pod 수>

 

Kubernetes Object - Service

Service	Pod에 접근하기 위해 사용하는 Object  -> Pod에 직접 접근이 아닌 서비스를 통한 접근 Kubernetes 외부 또는 내부에서 Pod에 접근할 때 필요 고정된 주소를 이용하여 접근이 가능 Pod에서 실행중인 애플리케이션을 네트워크 서비스로 노출시키는 Object
서비스에 필요한 Label	Pod와 같은 Object에 첨부된 키와 값 쌍 Key와 Value 형태로 존재
서비스에 필요한 Selector	특정 Label 값을 찾아 해당하는 Object만 관리할 수 있게 연결 서비스에 연결할 Pod와 같은 라벨
비슷한 형태인 annotation	Object를 식별하고 선택하는 데에는 사용되지 않으나 참조할 만한 내용들을 Label처럼 첨부 주석같은 역할

 

Service Motivation

Service 유형

ClusterIP (default)	Service가 기본적으로 갖고있는 ClusterIP를 활용하는 방식입니다. 서비스 유형을 지정하지 않으면 기본적으로 Cluster IP
NodePort	모든 Node에 Port를 할당하여 접근하는 방식입니다.
Load Balancer	Load Balancer Plugin 을 설치하여 접근하는 방식입니다.

 

ClusterIP(내부 접근)

ClusterIP 동작구조 시각화		외부에서 접근 불가능 Pod ip를 통해 직접 pod와 사용자를 연결할 수 있지만 pod가 재배포 될경우 ip가 변경되기 때문에 중간에 Service를 통해 연결 Cluster ip 용으로 9090 주소로 접근 Service에 9090으로 들어오면 8080으로 전달하라고 되어있음 8080으로 되어있는 3개의 pod에 트래픽을 분산해서 연결(Depoyment는 똑같은 pod를 3개로 분산한 것이기 때문에 어떤pod와 연결되어도 상관없다->이중화, 로드밸런스) ClusterIP는 Cluster안에서만 사용간능하다. 왼쪽 이미지의 파란점선박스를 의미 외부에서는 접근 불가능
ClusterIP YAML		왼쪽이 Service - ports에서 9090포트로 들어오면 8080포트로 전달  - type ClusterIP 오른쪽이 pod
ClusterIP kubectl	ClusterIP 유형의 Service를 생성하는 명령어 (서비스만 만듦)	kubectl create service clusterip clip --tcp=8080:80 kubectl create service clusterip --tcp=<포트:타켓포트>
	ClusterIP 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어	kubectl expose deployment nginx \ --port=8080 \ --target-port=80 \ --type=ClusterIP kubectl expose <연결할오브젝트> <오브젝트명> \ --port=<포트> \ --target-port=<타겟포트> \ --type=ClusterIP

 

NodePort(내부, 외부 접근)

NodePort 동작구조 시각화		ClusterIP에서 외부기능 추가 NodePort 부터는 외부에서 접근 가능함 노드가 할당받은 ip와 port를 이용한 접근 방식 서비스의 NodePort 30010로 부여했을 경우 외부 사용자는 어느 Pod의 노드인지 상관없이 노드 ip와 노드port로 접근을 하면 Service로 연결되어 Pod와 연결된다. NodePort 서비스는 클러스터 IP도 발급이 같이 되어 내부에서도 접속 가능하다.
NodePort YAML		해당 Node의 IP와 Node에 할당된 포트 번호 30010으로 접속을 하면 해당 서비스에 연결 Service는 자신에게 연결 되어있는 Pod에 트래픽을 전달 NodePort가 명시되어있지 않으면 랜덤하게 부여(30000 ~ 32767) externalTrafficPolicy가 Local로 설정되어 있는 경우 분산된 Pod 연결이 아닌 접속할 때 입력한 Node를 가진 Pod와 연결
NodePort kubectl	NodePort 유형의 Service를 생성하는 명령어	kubectl create service nodeport np --tcp=8080:80 kubectl create service nodeport --tcp=<포트:타켓포트>
	NodePort 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어	– kubectl expose deployment nginx \ --port=8080 \ --target-port=80 \ --type=NodePort kubectl expose <연결할오브젝트> <오브젝트명> \ --port=<포트> \ --target-port=<타겟포트> \ --type=NodePort

 

Load Balancer(내부, (노드+포트)외부 접근, 플러그인(로드밸러스 공인IP)외부 접근

Load Balancer 동작구조 시각화		외부 공인 IP를 통해 외부에 노출시켜 접근 ClusterIP, NodePort 서비스도 포함되어 있는 서비스이다
Load Balancer YAML		온전한 Load Balancer 의 기능을 사용하려면, 추가 플러그인 설치가 필요 또는 로드밸런서를 지원해주는 클라우드 환경에서 사용가능 클라우드 기반의 쿠버네티스(k8s)를 사용하면 공인 IP 발급 가능 서비스 ex) AWS -EKS Azure - AKS GCP - GKE
LoadBalancer - kubectl	LoadBalancer 유형의 Service를 생성하는 명령어	kubectl create service loadbalancer lb --tcp=5678:8080 kubectl create service loadbalancer --tcp=<포트:타켓포트>
	LoadBalancer 유형의 Service를 nginx라는 Deployment와 연결하여 생성하는 명령어	kubectl expose deployment nginx \ --port=8080 \ --target-port=80 \ --type=LoadBalancer kubectl expose <연결할오브젝트> <오브젝트명> \ --port=<포트> \ --target-port=<타겟포트> \ --type=LoadBalancer

 

---

Kubernetes DNS

Kubernetes DNS 개념

Kubernets는 Pod와 Service에 DNS 레코드를 생성합니다. IP 대신, 이 DNS를 활용하여 접근 할수 있습니다. -> FQDN(FullyQualifiedDomainName)

 

FQDN 구성 - Service / Pod

Service

NameSpace의 이름	ns1
Service 이름	svc1
Service에 접근 가능한 FQDN	svc1.ns1.svc.cluster.local (서비스이름.네임스페이스 이름.뒤에는 공통)

 

 

Pod

NameSpace의 이름	ns1
IP( '.' 이 '-' 로 바뀜)	10-10-10-10
Service에 접근 가능한 FQDN	10-10-10-10.ns1.pod.cluster.local (IP 주소.네임스페이스 이름.뒤에는 공통)

-> IP 기반으로 만들어져 있다: IP를 사용하지 않기 위해 DNS 를 사용하는데 IP가 사용되고 있다.

호스트 네임과 서브 도메인 개념이 추가로 필요하다.

 

DNS YAML

NameSpace의 이름	ns1
Hostname 명	hn1
Subdomain명	sd
Service에 접근 가능한 FQDN	hn1.sd1.ns1.svc.cluster.local (Hostname명.Subdomain명.Namespace명.뒤에는 공통)

 

---

Volume

Volume 개념	Kubernetes에서 Volume은 Pod 컨테이너에서 접근할 수 있는 디렉터리라고 생각할 수 있습니다. Pod 안에 컨테이너들은 네트워크와 볼륨을 공유한다.
Volume 개념 시각화
Volume 유형	EmptyDir / HostPath / PV/PVC

 

Volume 유형 - Emptydir

Emptydir 개념	비어있는 디렉토리 Pod가 생성될 때 함께 생성되고, Pod가 삭제될 때 함께 삭제되는 임시 Volume Pod에 종속된 Volume
Emptydir 시각화		Pod 안에 컨테이너 안에 설정없이 빠르게 볼륨을 사용할때
Emptydir YAML		Pod 안에 containers 에 대한 설정과  - 볼륨 사용 volumes에 대한 설정이 있다. - cache-volume 라는 이름의 emptyDIR {}

 

Volume 유형 - HostPath (Emptydir 단점 극복)

HostPath 개념	Pod의 종속성을 제외한 Volume 호스트 노드의 경로를 Pod에 마운트하여 함께 사용하는 유형의 Volume
HostPath 시각화		Node의 경로를 Volume으로 만들어서 Pod 안에 Container들이 사용해서 Pod가 삭제되어도 Volume이 삭제되진 않는다.
HostPath YAML		volumes: 에 hostpath 설정 path: /data -> 경로설정
HostPath - Pod 의 재생성 시		Node1 에서 Node2로 Pod가 재배포 될 때 Node2로 연결하면 연결성이 끊어진다. 수동으로 다시 연결해야한다.
HostPath - Pod 의 장애 시		Node1 장애가 일어날 때 Node2가 재생성되어 Pod는 재생성 되는데 볼륨은 Node2에 접근이 되지 않는다.

 

Volume 유형 - PV와 PVC (HostPath 단점 극복)

PV	Persistent Volume  Volume 자체를 의미  클러스터 내부에서 Object처럼 관리 가능  Pod 와는 별도로 관리  클라우드 서비스에서 제공해주는 Volume 서비스를 이용할 수도 있고, 사설에 직접 구축 되어있는 스토리지를 사용 가능  Pod에 직접 연결하지 않고 PVC를 통해서 사용
PVC		PersistentVolumeClaim 사용자가 PV에 하는 요청 Pod와 PV의 중간 다리역할
PV & PVC		Volume을 PV로 만들어 구성하여 PVC를 통해 Pod와 연결
PV YAML		볼륨을 Local 볼륨(5G) 사용 접근 모드 : RWO 다양한 접근모드 – RWO : 읽기,쓰기 / 하나의 Pod만 연결 – ROM : 읽기만 / 다수의 Pod 연결 – RWM : 읽기, 쓰기 / 다수의 Pod 연결 PV Label과 연결
PVC YAML		볼륨 2G 요청 접근 모드 RWO 요청과 접근모드에 알맞은 PV와 연결 PV Selector와 연결

 

추가) 스토리지 클라스: 클라우드 기반의 k8s에서 사용

Storage Class - YAML		스토리지 클래스 설정 위: AWS 아래: Azure AWS 의 EBS를 사용하는 StorageClass  Azure 의 Disk를 사용하는 StorageClass
PVC YAML (StorageClass)		sc-aws-ebs라는 StorageClass의 설정으로 PV를 동적으로 배포하는 PVC YAML  aws 의 ebs에서 자동으로 Pv를 만들어준다.(동적으로)