Managing Deployments Using Kubernetes Engine - Qwiklabs 실습

다음의 Qwiklabs 과정을 거치면서 모르던 내용들 그리고 배웠던 내용들에 대해 써보았다:

• Managing Deployments Using Kubernetes Engine

우선, 저 과정을 거치면서 모르거나 새로 배운 내용들에 대한 정의를 써보도록 하겠다. 나름 나의 해석?도 들어가 있는 것이라 정확하지는 않을 수도 있으나, 최대한 찾아본 내용을 토대로 썼다:

• On-Premise: 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 서버에 직접 설치해 운영하는 방식을 말한다
• Vendor Lock-In: A situation where the cost of switching to a different vendor is so high that the customer is essentailly stuck with the original vendor
• Heterogeneous Deployment: Common scenarios where heterogeneous deployment is used are multi-cloud deployments, fronting on-premises data, continuous integration/continuous delivery(CI/CD) processes
  • Fronting on-premises data: Architect and deploy cloud-based apps that can access private data systems of infrastructure
  • CI/CD Process: Software engineering approaches that are a part of the larger software delivery pipeline. They can help ensure that software is high quality, reliable, and safe and secure.
• Vi: Short for visual editor and displays a window into the file being edited
• :wq: A command line for exiting the visiual editor
• Configmap: A dictionary of configuration settings. Consists of key-value pairs of strings
• Scale a Deployment: When you scale an application, you increase or decrease the number of replicas
• Grep: 유닉스를 위해 만들어진 텍스트 검색 기능을 가진 명령어이다
• Rolling Update: Rolling updates allow deployments' update to take place with zero downtime by incrementally updating pods instances with new ones:
• Zero downtime: Describes a site without service interruption
• Canary Deployments: Consists of a separate deployment with your new version and a service that targets both your normal, stable deployment as well as your canary deployment
• Session affinity: =Sticky sessions. A platform feature that associates all HTTP Requests coming from an end-user with a single application instance A process in which a load balancer creates an affinity between a client and a specific network server for the duration of a session
• Blue-Green Deployments: 애플리케이션 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 release model. 이때 두 버전 모두 production 환경에서 실행 상태를 유지한다.
• TLS-Certs: TLS는 Tansport Layer Security로, TLS is a protocol that establishes an encrypted session between two computers on the internet. It verifies the identity of the server and prevents hackers from intercepting any data. TLS Certificate is a type of digital files that is used to certify the ownership of a public key

 

1. Rolling Update

Rolling Updates - 출처: <https://www.qwiklabs.com/focuses/639?parent=catalog>

 

보이듯이, 기존에 존재하는 3개의 replicas들을 분리시켜, 하나는 hello app version 2에 천천히 옮기는 방식이다. Replica 하나가 업데이트 되면, version 1에 존재하던 replica를 version 2 app에 옮겨서 서서히 업데이트 시키는 방식이다. 참고할 점은 replicas = Pods 이라는 점이다. 이를 하기 위해서는 다음과 같은 방법을 진행하면 된다:

kubectl edit deployment hello

 

hello라는 deployment를 수정하는데, containers의 image section을 수정시켜준다:

vi deployments/hello.yaml
i

vi로 deployments에 들어가서 i로 editor를 실행시킨다:

...
containers:
	image: kelseyhightower/hello:2.0.0
...

다음과 같이 원래 hello:1.0.0의 부분을 2.0.0으로 변경시킨다. 그러고는 Esc를 누르고 :wq를 누르고 엔터키로 빠져나온다. 확인해본다면 rolling update의 상태를 확인할 수 있다:

kubectl rollout status deployment/hello

 

 

2. Canary Deployment

Canary Deployment - 출처: <https://www.qwiklabs.com/focuses/639?parent=catalog>

Canary Deployment는 아예 새로운 deployment를 만들어서 한 service가 두 deployments 안에 있는 replica들을 관리하는 방식이다. Service 에서는 서비스중인 request 중 일부를 신규 ReplicaSet 으로 보내게 된다. 그리고 사용자는 새로운 version이 정상적으로 작동하는지 확인할 수 있다.

Rolling Updates와 다르게, Canary Deployment는 deployment system이므로, 다음과 같이 입력만 하면 된다:

kubectl create -f deployments/hello-canary.yaml

 

 

 

3. Blue-green Deployments

Blue-green Deployments - 출처: <https://www.qwiklabs.com/focuses/639?parent=catalog>

두개의 다른 deployments를 만들어, 기존의 deployments는 그대로, 다른 반대의 deployment에서는 업데이트 하는 방식으로 한다. 그리고 service는 기존의 deployment에만 작동되게끔 설정한다. 하지만 문제점은 2개의 거의 동일한 deployment를 돌리기 때문에, 2배의 용량이 필요하다는 것이다. Blue-green Deployment를 시작하기 전에는 이 부분을 확인하고 해야될 것이다.

기존의 방식과는 다르기 때문에 기존에 존재하던 deployment에 blue를 부여하고, 새롭게 만드는 deployment에 green을 부여하는 방식으로 시작된다:

kubectl apply -f services/hello-blue.yaml

기존 service에 hello-blue를 부여한다.

 

kubectl create -f deployments/hello-green.yaml

그리고 hello-green를 deploy 한다. 이때에도 service는 아직 blue deployment를 사용하고 있다.

 

kubectl apply -f services/hello-green.yaml

 

이렇게 할 경우, green deployment로 service가 옮겨간다. 다음과 같은 코드로 version 2에 service가 옮겨갔는지 확인할 수 있다:

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

 

Blue-green deployment를 rollback 하고 싶은 경우, 단순히 hello-blue에 service를 apply 시켜주면 된다:

kubectl apply -f services/hello-blue.yaml

 

위에 나와있는 코드로 version 1으로 service가 옮겨졌는지 확인 할 수 있다.