cka05 lifecycle management 정리한 것

이 글은 udemy의 <Certified Kubernetes Administrator (CKA) with Practice Tests > 강의를 들으며 자격증 공부 목적으로 내용을 정리한 글입니다. 

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests

Certified Kubernetes Administrator (CKA) Practice Exam Tests

 

[Rollout]

- a new rollout creates a deployment

- rollout helps us keep track of the changes make to our deployment and enables us to roll back to a previous version of deployment if necessary

kubectl rollout status deployment/myapp-deployment

- to see the revisions and history of rollout ,

kubectl rollout history deployment/deployment-name

□Deployment strategy

-First way to upgrade existing deployment to a newer version is to destroy all of these and then create new versions

-the old replica was scaled down to zero at first, then the new replica set scaled up to five

-문제점: 앱이 잠깐 다운되고 사용자들이 접근할 수 없음

-두번째 방법(Rolling Update): we take down the older version and bring up a newer version one by one (쿠버네티스의 default 방법)

-the old replica set was scaled down one at time, simultaneouslt scaling up the new replicaset one at a time

kubectl apply -f # update

-set 명령어로 해도 됨

# 이미지 변경
kubectl set image deployment/myapp-deploy nginx=nginx:1.9

#주의할 점: yaml파일과 다른 설정을 가지게 됨

-kubernetes deployment allows you to rollback.

to a previous revision to undo a change 

kubectl rollout  undo deployment/myapp-deplomeny

 

[command and arguments of Docker]

docker run ubuntu
docker ps -a  #see process inclusing Exited status

docker run ubuntu [COMMAND]
docker run ubuntu sleep 5

FROM Ubuntu

CMD sleep 5 # CMD ["sleep", "5"]와 같음

 

[command and arguments of POD]

docker run --name ubuntu-sleeper ubuntu-sleeper 10

해당 도커 파일에 대한 POD만들기

apiVersion: v1
kind: Pod
metadata:
 name: ubuntu-sleeper-pod
spec:
 containers:
 - name: ubuntu-sleeper
   image: ubuntu-sleeper
   args: ["10"]

만약 도커 명령어에 다음과 같이 entrypoint가 있다면

docker run --name ubuntu-sleeper \
           --entrypoint sleep2.0
           ubuntu-sleeper 10

pod에는

apiVersion: v1
kind: Pod
metadata:
 name: ubuntu-sleeper-pod
spec:
 containers:
 - name: ubuntu-sleeper
   image: ubuntu-sleeper
   command: ["sleep2.0"]
   args: ["10"]

 

[Enviroment Variables]

Env Value Types:

  1) Plain Key Value

  2) ConfigMap

  3) Secrets

 

1) Plain Key Value

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    env:
    - name: APP_COLOR
      value: pink

2) ConfigMap

env:
 -name: APP_COLOR
  valueFrom:
     configMapKeyRef:

3) Secrets

env:
 - name: APP_COLOR
   valueFrom:
      secretKeyRef:

 

[ConfigMaps]

APP_COLOR: blue
APP_MODE: prod

<Imperative>

kubectl create configmap <config-name> --from-literal=<key>=<value>

kubectl create configmap <coinfig-name> --from-file=<path-to-file>

<Declarative>

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_COLOR: pink
  APP_MODE: mode

ConfigMap in PODs

 

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    envFrom:
    - configMapRef:
          name: app-config

 

[Secret]

-secrets are similar to configMap except that they're stored in an encoded or hashed format as with configMaps

<Imperative>

kubectl create secret generic <secret-name> --from-literal=<key>=<value>

<Declarative>

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  DB_Host: <echo -n 'mysql' | base64>
  DB_User: <echo -n 'root' | base64>
  DB_Password: <echo -n '1234' | base64>

pod에 inject

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    envFrom:
    - secretRef:
         name: app-secret

 

<Simgle Env>

env: 
 -name: DB_Passwd
  valueFrom:
    secretKeyRef:
       name: app-secret
       key: DB_Password

 

[Multiple Container PODs]

-the idea of decoupling a large monolithic application into subcomponenets, known as microservices, enables us to develop and deploy a set of independent small and reusable code

-this architecture can help us scale up and down as well as modift each service as required as opposed to modifying the entire application (ex, web-server&Log)

-they can refer to each other as localhost and they have access to the same storage volumes

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
  - name: log-agent
    image: log-agent