[Kubernetes] 기말고사 정리 2

 

 

 

 

 

Chap19. Controllers 
- 쿠버네티스는 여러 SW들의 집합체 

* Controllers 

- take care of routine tasks to ensure the desired state (얌파일) of the cluster matches the observed state (현상태)

- Each controller is responsible for a particular resource in the Kubernetes 
- 사람이 개입하는 일이 줄어듦 - 직접 손으로 입력하지 않아도, 수많은 쿠버네티스를 구성하는 SW들이 개발자가 요구하는 환경(desired state)을 observed state로 최대한 제공해야 함 / 개발자는 쿠버네티스에게 부탁함 

 

* Label – key-value pair – pod과 같은 objects에 attached 
- 도커에서는 내 컴퓨터를 가정함, 쿠버네티스에서는 어느 컴퓨터에서 어떻게 동작할 지 알 수 없dma
- desired state를 요구할 뿐이지, 클러스터 안 노드들 중 어디서 동작할 지 알 수 없다. IP Address 대신 라벨을 사용
- 라벨로 명령이나 부탁이 적용되길 바라는 pod들의 집합을 의미 (그루핑의 기능) 

 

* Kubernetes pods are mortal - pod도 중간중간 죽을 수 있다 / 수명이 있다 

-> pod을 새롭게 띄워서 desired state를 유지함 – 따라서 IP address는 언젠가는 바뀔 정보 / 죽고 새로운 애가 만들어지면 IP가 바뀜
- 쿠버네티스는 팟들이 대화할 때, 개별 pod의 정보인 IP address를 사용하지 않음 - 라벨로 접근함, 직접 접근하지 않도록, 중간을 끊음

- IP를 안다? 누가 몇 개 있는지 빤히 안다 - 이런 결합성 지양
- the set of pods running in one moment in time could be different from the set of Pods running that application a moment later 

+ 이걸 운영하는 건 쿠버네티스가 알아서 할 것이다 / 서비스(node port) 이런 애들이 바깥에 붙음 (트래픽을 받음)
- 중간에 있는 서비스가 내 뒤에 3개의 팟이 있구나 -> 쉬는 애한테 일을 더 줘야지 (로드밸런싱) 
- 바깥에서 안의 ip를 볼 필요 X / 서비스까지만 오면 뒤로 알아서 보냄 + 서비스라는 애 마저도 뒤에 팟들을 바라볼 때 label (app:myapp)으로 찾아서, 접속하면 된다 / 뒤에 있는 애들의 IP Address를 알 필요가 없다 -> 라벨을 씀

 

* ReplicaSet – to maintain a stable set of replica Pods running at any given time
- To guarantee the availability of a specified number of identical Pods 
- 도커에서는 replicas 명령으로 개수 지정 / 쿠버네티스는 replica set controller에게 내가 원하는 상태를 전달하면, 
원하는 개수만큼 안정적으로 수행 - Replica set 얘도 SW
- A ReplicaSet creates & delete Pods as needed to reach the desired state 
- 우리가 replica set controller에게 줄 때 3가지 정보를 준다 

1) 이런 팟이야 (기존 얌파일 = pod template)
2) number of replica - 이걸 몇 개 실행해주세요

3) selector - 라벨을 전달 + IP Address 대신 셀렉터로 식별

+ Set-based Requirement – filtering keys according to a set of values 
ex) environment in (Production, qa) / tier notin (frontend, backend) – in, not in, exist 등 
ex) kubectl get pods -l environment=production, tier=frontend           // -l 라벨에 대한 조건을 의미함

 

 

 

simple-replicaset.yaml

 

 

 

* ReplicaSet은 class임 (kind가 클래스를 의미함)
- 즉, ReplicaSet 객체를 하나 만들어서 띄우는 것과 동일한 의미
- 이게 simple-replicaset.yaml 얌파일의 의미 
-> 라벨을 my-little-pod으로 초록색을 3개 띄워달라고 rs에게 부탁하는 것

 

+ IP address는 무용지물 / label을 써야한다.

* Service Distribution in ReplicaSet (Rolling) 
- 구르는 것처럼 서비스가 하나하나 천천히 바꾸는 것
- 3개의 pod을 update 하려면, 하나하나씩 끊고, 새롭게 연결함 -> rolling update
- 하나씩 바꾸면서 진도가 나감 / 롤백은 하나씩 뒤로가는 것 (원복)
- 회색을 하나 만들고, 녹색을 지운다

 

* Apply my-replicaset 
- kubectl apply -f simple-replicaset.yaml    // 해당 디렉토리의 파일을 활용하여 

 

 

 

Chap20. Kubernetes Objects & kubecctl Commands 

- 클래스로부터 객체를 만드는 것과 유사한 동작
- CRUD의 대상이 리소스(객체) / restful interface를 사용하여 리소스를 생성하고 업데이트, 삭제하는 용도로 사용함
- API의 URL이 어떤 리소스, 어떤 객체를 생성할 것인지를 의미함
+ 도커의 개발 환경은 나 스스로 -> API 호출이 큰 의미 없었음

- 쿠버네티스는 얌파일or 손으로 하던 것을 restfulAPI를 정의하여 호출함

- 얌파일 있던 kind가 리소스타입을 의미 

- class로부터 인스턴스가 만들어진다는 것이 객체지향의 컨셉과 동일하다
- A resource is an object with a type, associated data, relationships to other resources, and a set of methods 
- it it similar to an object instance in an object-oriented programming language, with the important difference that only a few standard methods are defined for the resources (get post put and delete) while object instance는 많음

 

* Record of Intent – 쿠버네티스에게 your cluster’s desired state를 전달 
- All objects have common metadata – 얌파일을 의미 / 운영하는 입장에서는 intent 라는 말을 많이 한다
- 다 자동화를 하는 것 + 본인의 의사(desired state)만 밝히는 것

+ policy = 조건문을 주는 것 / CLI로 보내야 할 명령을 API로 호출하는 것 
ex) CPU 보니깐 간당간당, pod을 더 띄워야겠어 등 손으로 하던 커맨드라인들을 API를 사용하여 자동화 가능 
- 이러한 API에 대해 Official Kubernetes Client Libraries가 언어별로 제공됨 

- 얌파일로 spec을 명시한다 – 이게 우리의 intent (desired state) 
- 쿠버네티스가 운영하는 상황 - status (object의 실제 상태) / 시간에 따라 상태가 변하면, 쿠버네티스가 업데이트 함

 

* Deployment – is an object that can represent an application running on your cluster 
- replica set은 기능적, 코드상으로는 kind만 ReplicaSet -> Deployment로 바뀜 
- kubectl apply -f simple-deployment.yaml 

+ 3개의 pod 중 어느 pod의 nginx로 가고 있는거지? log 명령어를 통해 볼 수 있다
 -> load balancing 으로 3개의 pod들이 번갈아 가면서 답하는 것을 확인할 수 있다

+ Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. + Recommend using Deployments instead of directly using ReplicaSets // Deployment resource makes it easier for updating your pods to a newer version // automatically without any human interaction and increases the abstraction by one level.

 

 

 

Chap21. Dashboard
- 필요한 Pod을 띄우고 모니터링한 이후, 새로운 pod 띄우기 

+ 버전 업그레이드, 다운그레이드 등 다양한 작업을 자동화해주는 deployment controller (지난 시간) 

- 쿠버네티스는 웹 서버처럼 dashboard를 제공한다 

– 사내 특정 화면을 보여주는 대시보드를 많이 개발, 오픈소스

- minikube dashboard (--url) 
- kubectl apply -f simple-deployment.yaml --record 

+ Pod들이 생성되고, 죽는 과정을 동적으로 UI를 통해 확인할 수 있다. 
- pod을 강제로 delete 죽이면 replicaset이 하나 더 살림 (desired state 유지하려고) 
- Scale Up & Down, Deployment yaml 파일 update도 가능 

 

 

 

Chap22. Services 
* Pods – mortal - 다양한 이유로 pod은 중간에 죽을 수 있음 + 죽었다 살아난다고 같은 애는 아님 (동적이다)
- 스케일링 업, 다운도 가능 + IP address가 큰 의미 없음 

* How do those frontends find out and keep track of which backends are in that set? 
+ 앞에서 요구를 받아주는 pod들이 프론트엔드 / 뒤에서 작업을 해주는 backend pods / 답: 라벨과 셀렉터

 

* Services – an abstraction which defines a logical set of Pods and a policy by which to access them 
- 서비스를 제어하기 위한 목적으로 LabelSelector 사용 – set of pods targeted by a Service is determined by LS

+ pod들이 IP address를 갖지만, 이걸 갖고 작업하지는 않음 - Cluster 바깥으로는 아무 의미가 없음 
-> 외부로 네트워크에 구멍을 뚫으려고 서비스 도입 

 

* Cluster IP Service – it is the default Kubernetes service – 최초의 서비스
- it gives you a service inside your cluster that other apps inside your cluster can access
- 외부 통신이 필요 없다 -> only cluster IP만 갖고 함 / there is no external access.

 

* NodePort Service - 클러스터를 구성하고 있는 노드에 구멍을 뚫어서, 외부에서 안으로 트래픽이 들어올 수 있도록 
- opens a specific port on all the Nodes and any traffic that is sent to this port is forwarded to the service. 

 

* Load Balancer Service - 별도의 분리된 물리적인 컴퓨터가 있을 때 쓰는 조금 더 똘똘한 네트워크 기능이 있다
- On GKE, this will spin up a Network Load Balancer that will give you a single IP address that will forward all traffic to your service (구글 쿠버네티스 엔진 like Docker-Hub)

 

* Ingress – it is actually not a type of service 
- it sits in front of multiple services and act as a “smart router” or entrypoint into your cluster

 

 

 

- 앞에 있는 애들을 갖고 진행되기 때문에 파일이 간결함 

- 따라서 앞선 two-replicas-with-label.yaml을 먼저 실행하고, 이 서비스를 돌리는 것
- 내가 select할 애들은 app이 eva인 것들 중 release가 west인 애들 / 그 pod 두 개가 node port 서비스에 연결됨
- NodePort: 외부에 공개, 통신할 수 있는 port number 80을 열어준다. 

- kubectl get pod -l app=eva -l release=west - 왼쪽의 pod 2개
- kubectl get pod -l app=eva -l release=east - 오른쪽의 pod 2개

* kubectl cluster-info -> 여기서 알아낸 쿠버네티스 서비스의 IP가 curl 명령어의 도메인(masterIP) 자리로 들어감
- curl http://192.168.64.2:30658    // 노드포트가 port 80을 32530에 mapping하여 열어둠
+ curl http://eva/                           // 어플리케이션의 이름, 라벨로도 접근이 가능하다!

+ Cluser IP – Cluster IP isn’t accessible from outside of the Kubernetes cluster. This is an internal IP only meaning that other pods can use a Services Cluster IP to communicate between them but we can’t just put this IP address in our web browser and expect to get connected to the service in our Kubernetes cluster. 

+ NodePort – A NodePort exposes a service on each node’s IP address on a specific port. 
- NodePort doesn’t replace ClusterIP however, all it does is direct traffic to the ClusterIP from Outside the cluster.
- NodePort must be within the port range 30000-32767

 

 

 

Chap23. Images and Registries
- 쿠버네티스 이미지는 도커와 동일한 이미지 - 이를 바탕으로 pod을 실행한다
- you need to push it to a registry before referring to it in a Kubernetes pod 
+ The default pull policy is IfNotPresent which causes the kublet to skip pulling an image if it already exists 

* ImagePullPolicy

1) IfNotPresent – the image is pulled only if it is not already present locally - 본인의 로컬에 없다면 가져오는 정책
2) Always – the image is pulled every time the pod is started - 본인의 로컬에 있던 없던 가져오는 것
3) Never – the image is assumed to exist locally – No attempt is made to pull the image 

 

* Why You Should Avoid :latest tag - immutable vs muttable 
- 버전이 고정되었다면 좋겠다 (immutable) - 하나의 버전이 명시적으로 운영 / latest라면 1과 2가 혼용될 우려점
-> 버전 트랙킹의 에러사항이 있으니, 정확히 버전을 명시하자 (latest 말고) 

 

* 상용 서비스에 사용가능한 registry – public cloud provider들이 제공하는 쿠버네티스 registry들
- 아마존의 ECR – Elastic Container Registry / EKS - 쿠버네티스 서비스
- MS Azure Container Registry / IBM Cloud Container Registry / Google Container Registry – gcr 샘플들 많음

 

 

 

Chap24. Scale and Rolling Updates 
- pod의 수를 늘리고, 줄이는 Scale / 버전 업데이트와 관련된 Rolling / 이론은 복잡하지만, 명령은 매우 간단

* Scaling – 트래픽이 증가하면, deployment의 replicas 수를 바꾼다 
- 하나의 pod으로 구성된 서비스 A에 3개의 Pod를 추가하여 scaling up + 노드도 2개 더 추가된 상황 
- 역으로 진행되는 오른쪽에서 왼쪽이 scaling down (pod의 수를 줄이는 것)

 

* Rolling Updates – deployments’ update to take place zero downtime by incrementally updating pods instances with new ones –> updates can be reverted to previous version – pod의 수가 아니라 성질(버전)이 변하는 것!
- 버전이 바뀌는 것이 달라짐 (초록색 -> 보라색으로 하나하나 교체) 

- 초록 버전으로 돌아가는 4개의 pod을 보라색 버전으로 바꾸고 싶다 
- immutable (동일한 버전)에 대한 중간 과정이 있음 - final에서는 모두 보라색으로 변화함 (smooth)
- 외부 IP는 변화 X // 내부 IP는 모두 바뀜! 

 

* Scaling & Rolling Updates 실습
- kubectl scale deployments/Kubernetes-bootcamp --replicas=2         // scaling
- kubectl set image deployments/Kubernetes-bootcamp kubernetes-bootcamp=jocatalin/Kubernetes-bootcamp:v2
-> 명령어 한 줄이지만, 쿠버네티스가 많은 일들을 한다 – image의 버전을 구글 -> 조캐틀린으로 바꾼다는 의미 

- Rolling - 새로운 이미지를 하나 만듦, 기존 이미지 pod를 하나 죽임, 새 이미지를 하나 늘리고, 
기존 pod 하나 더 죽여서 update를 끝낸다! curl로 붙어보면, version이 1에서 2로 바뀐 것을 알 수 있음

- kubectl rollout history deployment.apps/kubernetes-bootcamp : revision에 대한 이력(로그 정보)을 볼 수 있음
- kubectl rollout undo deployment.apps/kubernetes-bootcamp : 앞서 했던 rollout 작업을 취소시킨다 roll-back
- kubectl rollout undo deployment.apps/kubernetes-bootcamp --to-revision=1 // 특정 단계로 돌아가고 싶으면 명시

 

 

 

Chap25. Stateless and Stateful Applications 
- 지금까지 우리가 한 건 stateless – ex) 간단한 웹서버 request & response 
- stateful - 메모리가 있어서, 정보가 저장되어야 함 -> 메모리가 있는 기준으로 하는 서비스 의미

* Stateless – doesn’t save client data generated in on session for use in the next session with that client
- there is no memory of the past - 서버가 기존 기록을 바탕으로 판단 X / 현재 시점의 요청만으로 판단하는 것

 

* Stateful – saves client data from the activities of one session for use in the next session 
- 과거의 일, 데이터 저장 / 볼륨이나 스토리지 등 메모리 / 과거 트랜잭션의 정보가 남아, 현재 트랜잭션에 영향 O 

+ stateless - rolling에 강점, 이미지 update가 자유로움 / 과거 데이터가 없으니, 버전 변경에 어려움이 없음
- 과거 정보와 새로운 정보가 독자적으로 운영 가능 -> 지금 상태에 의해 결정이 내려진다.
- 기존 deployment를 new로 덮어버리는 것 ex) nginx 1.14.2 -> 1.16.1 (new version) 
- kubectl apply -f https://k8s.io/examples/application/development-update.yaml            // 새 버전으로 덮인다
- kubectl apply -f https://k8s.io/examples/application/development-scale.yaml               // replica만 2->4 바뀜 

 

 

 

Chap26. Storage - 도커와 비슷하지만, k8s 더 다양한 볼륨들이 있다.
(1) 컨테이너는 비정상적으로 죽었다 살았다 -> 데이터는 이와 분리되도록 – Data persistency
(2) 개별 컨테이너들이 file 형태의 정보를 공유함 -> 이를 위한 스토리지 – Shared resources 

 

* Volume -is just a directory, possibly with some data in it, which is accessible to the containers in a pod. 
- volume type - 메모리, 파일 디스크인지 더 구체적으로는 HDD, SSD 등 // 쿠버네티스의 영역이라기에는 옳지 않음
- 도커 컨테이너 안의 임시 공간 : Asset(emptyDir)    // host node의 특정 디렉토리를 binding : host path (Cache)

+ 위험한 조건 - 앞의 리퀘스트를 처리했는데, 걔가 죽어버리면? stateful? 
-> 반드시 걔 바깥에 저장이 되어야 함 - 이건 컨테이너의 영역을 벗어나는 것
+ 쿠버네티스의 스토리지는 하나임 - persistent volume - 볼륨이 항상 존재한다.

 

* emptyDir – active as long as the Pod is running on that node (도커에서의 volumes – 도커 내부의 공간)
* hostPath – mounts a file or directory from the host node’s filesystem into your pod (도커에서의 bind - 마운팅) 
* nfs – network file system - 스토리지를 별도로 구축한 다음, 물리적으로 떨어진 애들을 논리적으로 연결해서 사용함
* PersistentVolumeClaim & PersistentVolume – a piece of storage in a Kubernetes cluster. 

+ 제대로 된 서비스를 하면서, 이전 고객 기억하고, 현재서비스 하려면 stateful하고자 하는 state는 뒤에 있어야 한다.
- 도커나 쿠버네티스의 영역이 아닌, 제3의 공간에 존재 -> public cloud 전문화된 스토리지 기술 (구글, 아마존, MS)
- DB 깨지면 장난 아님, 2중 3중으로 분리하는 기술 -> 쉽지 않음 or 본인의 전용 파일 서버를 연결하는 기술 (nfs)

 

* PersistentVolumeClaim & PersistentVolume – PV & PVC 

1) NFS - network file system
: F 디렉토리 같은게 생김 - 마치 내 물리적인 디스크같지만, 실제로는 네트워크를 통해 read write 하는 것
- like Remote Procedure Call (RPC)
- Cluster Admin이 NFS을 구축함

(2) 물리적인 node or cloud storage를 쓸 수 있는 형태로, 쿠버네티스 안으로 끌어들인다 - admin(운영팀)이 쿠버네티스에 정의된 형식으로 PV를 만든다. 
(3) User가 PVC를 create – 자기가 만들고 싶은거 이야기하면 됨 
(4) 쿠버네티스에 PV리스트 쭉 뜸 - 쿠버네티스가 적절한 PV를 사용자에게 bind 시켜준다. (bind PVC to PV)
(5) pod에서 volume 키워드로 접근하여 쓰면 됨 – User creates a pod with a volume referencing the PVC

+ Wrap-up – 10만 컨테이너 양병론
- 10만 개의 Container를 안정적으로 서비스 할 수 있는 기반을 만들어야 한다 (Cloud Native 환경)