89. Application Lifecycle Management - Section introduction

91. Rolling Updates and Rollbacks

92. Practic Test - Rolling updates and Rollbacks

94. Configure Applications

95. Commands

96. Commands and Arguments

97. Practice Test - Commands and Arguments

99. Configure Environment Variables in Applications 

100. Configuring ConfigMaps in Applications 

101. Practic Test: Environment Variables

103. Kubernetes Secrets

104. A note about Secrets! 

105. Practice Test - Secrets


 

 

 

89. Application Lifecycle Management - Section introduction

 

위와 같이 배워볼 것이다.

 

 

91. Rolling Updates and Rollbacks

 

Rollout and Versioning

deployment 를 만들면 rollout을 만든다. rollout 는 새로운 deployment revision을 만든다. (revision1)

 

새로운 deployment를 만들면 새로운 rollout 과 revision을 만든다. (revision2)

 

revision은 버전 관리에 도움을 준다 .

 

Rollout Command

rollout 을 명령을 하면 pod를 하나씩 교체한다. 

 history 로 확인 가능하다.

 

Deployment Strategy | recreate, Rolling Update

recreate 방식은 모든 인스탄스를 중지하고 새 인스턴스로 한번에 교체하는 것이다.

이때 application이 다운 될 수 있다.

rolling update는 하나씩 교체하는 것이다. 

application이 down 되지 않는다.

rolling update가 기본적인 배포 방식이다.

 

how to update deployment

yaml 파일에서 image 버전을 수정했다고 가정하자
apply 를 하면 변경 사항이 적용된다.

rollout 이 자동 실행된다. 

kubectl set image로 바로 image를 변경할 수 있다. yaml 파일에는 변경되지 않음.

recrate 를 자세히보면 replica를 0으로 줄였다가 5로 다시 늘린다. 

rollingupdate는 하나 줄이고 늘이고 반복하는 식이다.

만약 replica set 1 에서 2 로 업데이트를할때 

replica set2 의 pod 1 생성 set 1의 pod1 종료 

pod2 생성 set1의 pod2 종료 교차식으로 교체한다.

업데이트 완료된 후 확인하면 replicaset1 의 pod는 다 꺼지고 set 2의 pod는 잘 작동중인것을 확인할 수 있다.

 

만약 rollback 하고 싶으면 rollout undo 명령 

rollout 도 마찬가지로 하나씩 교체한다.

명령어 요약! 

 

 

92. Practic Test - Rolling updates and Rollbacks

1.

We have deployed a simple web application. Inspect the PODs and the Services

Wait for the application to fully deploy and view the application using the link called Webapp Portal above your terminal.

사이트 접속

2.

What is the current color of the web application?

Access the Webapp Portal.

blue

 

3.

Run the script named curl-test.sh to send multiple requests to test the web application. Take a note of the output.

Execute the script at /root/curl-test.sh.

/root/curl-test.sh

 

4.

Inspect the deployment and identify the number of PODs deployed by it

5.

What container image is used to deploy the applications?

 

6.

Inspect the deployment and identify the current strategy

7.

If you were to upgrade the application now what would happen?

 

8.

Let us try that. Upgrade the application by setting the image on the deployment to kodekloud/webapp-color:v2

Do not delete and re-create the deployment. Only set the new image name for the existing deployment.

 

CheckCompleteIncomplete

 

simple-webapp=<새로운 이미지 명>

 

9.

Run the script curl-test.sh again. Notice the requests now hit both the old and newer versions. However none of them fail.

Execute the script at /root/curl-test.sh

10.

Up to how many PODs can be down for upgrade at a time

Consider the current strategy settings and number of PODs - 4

25% 가 max 이므로 1개 

11.

Change the deployment strategy to Recreate

Delete and re-create the deployment if necessary. Only update the strategy type for the existing deployment.

 

12.

Upgrade the application by setting the image on the deployment to kodekloud/webapp-color:v3

Do not delete and re-create the deployment. Only set the new image name for the existing deployment.

 

13.

Run the script curl-test.sh again. Notice the failures. Wait for the new application to be ready. Notice that the requests now do not hit both the versions

Execute the script at /root/curl-test.sh.

 

 

 

94. Configure Applications

응용 프로그램 구성은 다음 개념을 이해하는 것으로 구성됩니다.

  • 응용 프로그램에서 명령 및 인수 구성
  • 환경 변수 구성
  • 비밀 구성

우리는 다음에 이것을 볼 것입니다

 

 

95. Commands

우분투 이미지를 가지는 도커 컨테이너를 운영한다고 가정해보자

docker 명령을 실행하면 우분투 인스턴스를 생성한다. 

process status 로 명령하면 아무 컨테이너도 뜨지 않는다.

Exited 상태에 있는 컨테이너를 볼 수 있다.

Containers are not meant to host an operating system.

컨테이너는 가상 컴퓨터와 달리 운영 체제를 호스팅하도록 되어있지 않다.

Containers are meant to run a specific task or process such as to host an instance of a web server or

application server or a database or simply to carry out some kind of computation or analysis once the

task is complete.

컨테이너를 운영체제가 아니다. 여러가지 task를 처리하는 하나의 수단일뿐. 

task를 완료하면 컨테이너는 exit 한다. 

 

컨테이너가 무슨 프로세스를 해야하는지 어떻게 정의를 내릴까?

docker 이미지 파일을 보면 cmd 파트가 있다.

해당 파트를 컨테이너가 할거다? 

mysql 의 이미지 파일
우분투 이미지

우분투 인 경우 cmd 에 ubuntu 가 아니라 bash 라고 쓰여있다.

bash는 터미널의 인풋을 듣는 조형물이다. 

웹서버  데이터베이스 서버 같은 프로세스가 아니다.

 

 

터미널을 찾을 수 없다면 container는 exit 할 거다. 

 

우분투 컨테이너가 생성되고나서 bash 는 터미널을 찾을 수 없기에 exit한다. 

기본값으로 Docker 는 실행 중일 때 컨테이너에 터미널을 연결하지 않는다 .

bash 프로그램은 터미널을 찾지 못해 종료된다.

 

컨테이너 생성시 다르게 옵션을 줘야할 필요가 있다.

 

 

sleep 5 옵션으로 5초동안 살아있다가 exit 한다 .

쉼표 추가

 

매번 시작할때마다 sleep 하도록 설정하는 법

배열의 첫번째 요소는 실행가능해야한다. 

sleeper 를 만들고 적용하기
sleeper 를 지정했다면 바로 10 을 뒤에 파라미터로 사용해도 된다.

Entrypoint 지정함으로서 컨테이너가 실행될 때 우선적으로 실행될 명령어를 지정한다.

 

초에 대한 파라미터를 안주면 에러가 뜬다.

In case of the CMD instruction the command line parameters passed will get replaced entirely, whereas

in case of entry point the command line parameters will get appended.

entrypoint 오버라이드 옵션으로 다른 명령어로 실행되게 할 수 있다.

 

 

96. Commands and Arguments

10초를 sleep 시키고 싶은면 args: ["10] 이렇게 주면 된다.

pod yaml 파일에서 args 에 변수를 입력하면 변수를 사용할 수 있다. 

entrypoint 를 오버라이드 할려면 --entrypoint 옵션을 주면 된다.

yaml 파일에서 command로 entrypoint 오버라이드를 할 수 있다.

 

좀 어렵다. docker 도 따로 공부해야겠다. 

 

 

97. Practice Test - Commands and Arguments

1.

How many PODs exist on the system?In the current(default) namespace

2.

What is the command used to run the pod ubuntu-sleeper?

command

3.

Create a pod with the ubuntu image to run a container to sleep for 5000 seconds. Modify the file ubuntu-sleeper-2.yaml.

Note: Only make the necessary changes. Do not modify the name.

 

4.

Create a pod using the file named ubuntu-sleeper-3.yaml. There is something wrong with it. Try to fix it!

Note: Only make the necessary changes. Do not modify the name.

 

5.

Update pod ubuntu-sleeper-3 to sleep for 2000 seconds.

Note: Only make the necessary changes. Do not modify the name of the pod. Delete and recreate the pod if necessary.

이렇게 바로 edit 이 안된다.

 

vi 에디터로 수정후
apply 하면 인자가 1200, 2000 두개가 뜬다.
이것도 안됨

edit 하고 생긴 파일로 replace 하자!

조금 기다리면 교체된다.

6.

Inspect the file Dockerfile given at /root/webapp-color directory. What command is run at container startup?

pythom, app.py

7.

Inspect the file Dockerfile2 given at /root/webapp-color directory. What command is run at container startup?

ep 가 지정되면 cmd의 내용은 ep의 파라미터가 된다.

8.

Inspect the two files under directory webapp-color-2. What command is run at container startup?

Assume the image was created from the Dockerfile in this directory.

docker 파일과 yaml 파일 같이 정의된 경우 yaml 파일을 따라간다. 

command --color, green 이 실행된다. 

 

9. 

Inspect the two files under directory webapp-color-3. What command is run at container startup?

Assume the image was created from the Dockerfile in this directory.

yaml 파일에 cmd 먼저 실행 arg 적용

 

10.

Create a pod with the given specifications. By default it displays a blue background. Set the given command line arguments to change it to green.

--help 로 확인하기

 

 

99. Configure Environment Variables in Applications 

쿠버네티스에서 환경 변수 설정하는 법!

containers 아래에 env 옵션을 추가한다.

name 은 환경 변수이름 value는 값

아니면 valueFrom 을 이용하여 configMapKeyRef, secretKeyRef 로 숨길 수 있다.

환경 변수를 적용하는 방법 

키 값,

컨피그맵

시크릿키 

100. Configuring ConfigMaps in Applications 

만약 pod 안에 환경 변수를 많이 넣으면 복잡할 거다. 

configMap 을 사용하면 key, value를 중앙에서 관리할 수 있다.

create configMap, Inject into pod 두단계로 나뉜다.

configMap 생성 방법 두가지 

 

create configMap - 명령형

kubectl create configmap

 app-config --from-literal=APP_COLOR=blue

바로 환경 변수를 입력한다. 

The from literal option is

used to specify the key value pairs in the command itself.

from-literal 옵션은 키, 값 바로 있을때

 

kubectl create configmap

 app-config --from-literal=APP_COLOR=blu \
 			--from-literal=APP_MOD=prod

환경변수를 추가하고 싶다면 위와 같이 한다. 

kubectl create configmap

 app-config --from-file=config.properties

파일로 넘겨줄 수 있다.

 

create configMap - 선언형

kubectl create -f config-map.yaml

하고 config-map.yaml 파일을 만든다. 

특이한 점은 spec 대신 data 가 들어간다는 점이다. 

create 까지 해야 configmap 이 구성된다. 

 

 

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_COLOR: blue
  APP_MODE: prod

configmap을 다양한 방식으로 이용할 수 있다. 

kubectl get configmaps

describe 도 가능함. 

Inject into pod

envFrom 을 추가하자.

pod 에 spec -> containers ->

envFrom:

  -configMapRef:

      name: app-config

 

이제 pod 를 실행 시키면 환경변수가 적용될 것이다 .

여러가지 방식으로 환경변수를 가져올 수 있다.

 

101. Practic Test: Environment Variables

1.

How many PODs exist on the system?in the current(default) namespace

2.

What is the environment variable name set on the container in the pod? 

3.

What is the value set on the environment variable APP_COLOR on the container in the pod?

pink

 

4.

View the web application UI by clicking on the Webapp Color Tab above your terminal.

5.

Update the environment variable on the POD to display a green background

Note: Delete and recreate the POD. Only make the necessary changes. Do not modify the name of the Pod.

변경하면 취소된다.

실행중인 pod를 변경한다고 해서 변경되지 않는다. manifest 파일을 수정해야한다. 

대신 수정한 카피에 대한 경로를 준다. 

그때 복제 파일 경로를 얻고 

기존 pod를 delete 하고 

create 한다. 

6.

View the changes to the web application UI by clicking on the Webapp Color Tab above your terminal.

If you already have it open, simply refresh the browser.

 

7.

How many ConfigMaps exists in the default namespace?

 

8.

Identify the database host from the config map db-config

 

 

9.

Create a new ConfigMap for the webapp-color D. Use the spec given below.

  • ConfigName Name: webapp-config-map

  • Data: APP_COLOR=darkblue

10.

Update the environment variable on the POD to use the newly created ConfigMap

Note: Delete and recreate the POD. Only make the necessary changes. Do not modify the name of the Pod.

 

11.

View the changes to the web application UI by clicking on the Webapp Color Tab above your terminal.

 

 

103. Kubernetes Secrets

비밀 번호 같이 사적인 데이터를 위처럼 표기한다면 위험하다. 

그래서 Secret 이 필요하다.

 

마찬가지로 create secret, inject into pod 두가지 단계가 필요함

명령형 , 선언형 생성가능하다.

명령형

kubectl create secret generic  

이렇게 생성한다.

선언형

키 ,값을 yaml 파일에 바로 집어넣으면 안되고 암호화된 값을 넣어야한다. 어떻게 변환 하는가 ?

위와 같은 명령어로 암호화 할 수 있다.

describe 로 보면 안에 데이터를 볼 수 는 없다. 

확인하고 싶다면 yaml 파일을 확인

-o yaml 옵션 사용

 

 

어떻게 복호화 할까 

decode 옵션을 사용하면 된다. 

secretRef inject 하기

envFrom 후에 

secretRef 로 추가한다.

 

위와 같은 방식으로 inject 하기

ls를 이용하면 secret 속성을 확인가능. 세개의 파일이 있음.

Secret은 완전히 암호화된 것이 아니다. 

그냥 인코딩 된것 

누구나 인코딩된 내용을 볼 수 있다. 

ETCD 에 암호화되지 않는다. 

github 이런데 올리지 마라 

클라우드 사업자이 제공하는 secret store 를 고려해보자! 

 

 

104. A note about Secrets! 

Remember that secrets encode data in base64 format. Anyone with the base64 encoded secret can easily decode it. As such the secrets can be considered as not very safe.

The concept of safety of the Secrets is a bit confusing in Kubernetes. The kubernetes documentation page and a lot of blogs out there refer to secrets as a "safer option" to store sensitive data. They are safer than storing in plain text as they reduce the risk of accidentally exposing passwords and other sensitive data. In my opinion it's not the secret itself that is safe, it is the practices around it. 

Secrets are not encrypted, so it is not safer in that sense. However, some best practices around using secrets make it safer. As in best practices like:

  • Not checking-in secret object definition files to source code repositories.
  • Enabling Encryption at Rest for Secrets so they are stored encrypted in ETCD. 

 

Also the way kubernetes handles secrets. Such as:

  • A secret is only sent to a node if a pod on that node requires it.
  • Kubelet stores the secret into a tmpfs so that the secret is not written to disk storage.
  • Once the Pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.

Read about the protections and risks of using secrets here

Secrets | Kubernetes

Having said that, there are other better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets, HashiCorp Vault. I hope to make a lecture on these in the future.

 

 

105. Practice Test - Secrets

1.

How many Secrets exist on the system?

2.

How many secrets are defined in the dashboard-token secret?

3

 

3.

What is the type of the dashboard-token secret?

 kubernetes.io/service-account-token

 

4.

Which of the following is not a secret data defined in dashboard-token secret?

 

 

5.

We are going to deploy an application with the below architecture. We have already deployed the required pods and services. Check out the pods and services created. Check out the web application using the Webapp MySQL link above your terminal, next to the Quiz Portal Link.

 

 

6.

The reason the application is failed is because we have not created the secrets yet. Create a new secret named db-secret with the data given below. You may follow any one of the methods discussed in lecture to create the secret.

  • Secret Name: db-secret

  • Secret 1: DB_Host=sql01

  • Secret 2: DB_User=root

  • Secret 3: DB_Password=password123

 

7.

Configure webapp-pod to load environment variables from the newly created secret.

Delete and recreate the pod if required.

  • Pod name: webapp-pod

  • Image name: kodekloud/simple-webapp-mysql

  • Env From: Secret=db-secret

 

8.

View the web application to verify it can successfully connect to the database

+ Recent posts