유튜브 따배쿠 시리즈
따배쿠 실습 코드

3. kebuctl 실습

3-2. kubectl command/ pod 생성하기

kubectl [command][TYPE] [NAME][flags]

• kubectl: 쿠버네티스 명령어 시작 커맨드
  (예시)
• kubectl get nodes: 노드 정보 조회
• kubectl run webserver --image=nginx:1.14 --port 80 : webserver 실행
• kubectl create deployment mainui --image=httpd --replicas=3 : httd라는 웹서버를 3개 실행
• kubectl exec webserver -it -- /bin/bash : 실행중인 컨테이너(webserver)로 접속

4.쿠버네티스 아키텍처

4-1.kubernetes 동작원리

쿠버네티스 동작 원리

1. 컨테이너 빌드
2. 만들어진 컨테이너들을 도커 명령어로 도커 허브에 저장
3. 쿠버네티스 명령어(kubectl)로, 쿠버네티스에세 컨테이너 실행해달라고 마스터(컨트롤 플레인)에게 요청
4. 마스터의 kubectl 요청을 받는 api서버는 어떤 작업 노드에서 요청을 처리하면 좋을지 마스터의 스케쥴러에게 질문
5. 스케쥴러는 계산해서 api 서버에게 응답 내려줌
6. api서버는 결정된 워커노드의 kubelet(데몬)에게 실행 요청 전달 ex. 노드1의 kublet아, 너가 nginx 하나를 실행해주면 좋겠어
7. kubelet은 그 내용을 도커명령어로 바꿔서, 노드1의 docker demon에게 전달
8. docker demon은 도커허브로 <nginx 컨테이너 있는지 검색> 후 컨테이너로 실행
   -> 이때, 이렇게 실행되는 컨테이너를 쿠버네티스가 POD라고 부름

기타

1. kublet안에는 cAdviser라는 컨테이너 모니터링 툴이 포함되어 있음
2. cAdviser는 컨테이너 기반의 상태정보를 수집해서 마스터(컨트롤 플레인)에게 전달
3. 마스터는 etcd저장소에 워커노드들로부터 전달받은 상태정보들을 저장하고 있음. << 스케쥴러는 api서버로부터 이 정보들을 전달받아, 어떤 워커노드에서 명령어 실행할지 결정함
4. 마스터의 컨트롤러: pod의 갯수(?) 를 보장해줌
   ex. nginx서버가 무조건 1개 떠있어야하면, 기존꺼 죽었을 떄 controller가 감지해서 추가해달라고 api 서버에 요청보냄
5. cni(container network interface): 컨테이너 간 통신을 지원해줌 ex. weave
6. 클러스터 로깅

• ELK, EFK, DataDog

4-2. namespace

namespace 설명

클러스터 하나를 여러 개의 논리적인 단위(컨트롤플레인+ 워커노드)로 나눠서 사용 (물리적인 실제 장비는 1개)

출처: https://youtu.be/pfkx8KDAZyk?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=489

1. 목적: 용도에 따라 실행해야 하는 앱을 구분할 때
   ex. real/stage/alpha 를 각각 namespace로 분리

2. 명령어: kubectl create namespace [blue/oragne/green]

3. 장점

   • 실제로는 물리장비를 나눠쓰는거지만, 아예 독립된 것처럼 kubectl 명령어 쓸 수 있음(따로 관리할 때 용이)

기타

1. 컨테이너 yaml 파일 > metadata 영역에 namespace를 지정하면, 실행시킬 때 다른 옵션 없을 경우 지정된 namespace가 디폴트가 되어 실행됨

namespace 관리

1. 베이스 namespace를 바꿀 수 있음

   • 원래는 default namespace임
   • 쿠버네티스 config 의 context에서 namesapce를 관리하므로, 새로운 베이스 namespace를 지정한 context를 생성해서 등록해야함
   • 등록 후 current-context 확인 함 -> 새로 등록한 context가 아닐 경우, 컨텍스트 변경해달라는 명령어 날려야 함

2. namespace 삭제하기

   • namespace 삭제하면, 안에서 동작중인 pod를 비롯한 모든 것이 지워짐

4-3. yaml템플릿과 API

yaml 템플릿 설명

• 사람이 쉽게 읽을 수 있는 데이터 직렬화 양식
• key-value 타입임
• 띄어쓰기를 주의해야함(들여쓰기시 tabx, 띄어쓰기o)
• 가독성이 좋아서, 설정 파일에 적합한 형식임

API version

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: orange
spec:

• kubernates object 정의 시 apiVersion이 필요함
  • api object의 종류: Deployment/ Pod/ ReplicaSet/ ReplicationController/ Service/ PersistentVolume
• kubernates가 업데이트하는 API가 있으면, 새로운 API가 생성됨
• api 버전알 수 있는 명령어: kubectl explain [pod]

5. Pod(파드)

목표

1. Pod 개념 및 사용하기
2. livenessProbe를 사용한 self-healing Pod
3. init container
4. infra container(pause) 이해하기
5. static pod 만들기
6. Pod에 resource 할당하기

5-1. Container 정리와 Single / Multi Container Pod 생성

Container 정리

출처: https://youtu.be/0rYt3PcggzA?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=270

• 컨테이너 하나 == 애플리케이션 하나

Pod이란?

• 컨테이너(들)를 표현하는 쿠버네티스 api의 최소 단위
• Pod에는 한개 or 여러 개의 컨테이너가 포함될 수 있음
  
  출처: https://youtu.be/0rYt3PcggzA?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=411

single-container Pod 생성방법

1. CLI에서 명령어로 직접 실행
   • kubectl run [webserver] --image=nginx:1.14
2. yaml 파일 만들어서 실행

   apiVersion: v1
   kind: Pod
   metadata:
     name: webserver
   spec:
     containers:
     - name: nginx-container
       image: nginx:1.14
       imagePullPolicy: AlwaysPorts:
       - containerPort:90
         protocol: TCP

   • kubectal create -f pod-nginx.yaml

multiple-container Pod 생성방법

컨테이너 간 유기적인 관계를 가지고, 연동이 되어 동작하는 방식 ex. 웹서버에 쌓이는 로그 수집하는 애플리케이션

• CLI 방식과 yaml파일 방식있음 (필요시 검색해서 알아보기..)

기타

1. POD가 제대로 동작안하면 describe 명령어로 살펴보기

5-2. Pod 동작 flow

Pod 동작 flow

1. 쿠버야, 나 웹서버 실행해줘!
   • kubectl run webserver --image=nginx:1.14
2. Pod 동작 상태 체크
   • kubectl get pods -o wide --watch
   • 예시
     Pending 상태 -> ContainerCreating -> running or SucceededFailed
     -> Terminating (Pod 종료시킬 때의 상태)

5-3. livenessProbe를 이용해서 Self-healing Pod 만들기

부제: kubelet으로 컨테이너 진단하기
(컨테이너 진단해서, 건강하지 않으면, restart하는 기능)

Liveness Probe 설명

• Pod가 계속 실행할 수 있음을 보장
• Pod의 spec에 정의(key값은 livenessProbe)

  apiVersion: v1
  kind: Pod
  metadata:
    name: webserver
  spec:
    containers:
    - name: nginx-container
      image: nginx:1.14
    livenessProbe:
      httpGet:
        path: /
        port: 80

• http 80포트로 /로 접속해서, 응답 여부에 따라 건강상태 판단

Liveness Probe 종류

애플리케이션마다 건강상태 판단 방법이 다르지 않나? 어떻게 각 특성마다 지원하지?

• 쿠버네티스는 3개의 방법을 지원함.

1. httpGet(웹서비스 애플리케이션)
   • 지정한 ip주소, port, path에 http get요청을 보내서, 해당 컨테이너가 응답(200 ok)하는지 확인
   • 200이 아닌 값이 내려오면, 컨테이너 재시작
2. tcpSocket(ssh 데몬이 서비스해주는 애플리케이션)
   • 지정된 포트에 tcp연결 시도.
   • 연결되지 않으면 컨테이너 재시작
3. exec
   • exec 명령 전달 -> 명령의 종료코드 확인
   • 0이 아니면 컨테이너 재시작

• 컨테이너 재시작이란?
  도커 허브에서 다시 컨테이너 받아와서, 재시작함! 컨테이너만 재시작이므로, pod의 ip주소 변경되지 않음

Liveness Probe 매개 변수

• periodSeconds: health check 반복 실행 시간(초)
• initialDelaySeconds: Pod 실행 후(==running상태가 된 후)delay할 시간(초)
• timeoutSeconds: health check 후 응답을 기다리는 시간(초)

기타

1. 현재 실행중인 pod의 실행정보?를 얻으려면?(목적: 이 pod을 기반으로 설정값 만지려고 할때?)

• kubectl get pod [nginx-pod] -o yaml

1. vm환경에서는 스크립트 파일을 만들어서 상태체크 했는데, 쿠버네티스는 자동으로 상태체크 해줌. 유용!

5-3. init container

init container 설명

• 앱 컨테이너(메인 컨테이너) 실행 전에, 미리 동작시킬 컨테이너
• 목적: 메인 컨테이너가 실행되기 전에 사전작업이 필요한 경우
• 동작방식: init컨테이너가 성공해야 -> main 컨테이너가 실행됨
• 예시: network가 정상이어야 -> 컨테이너가 정상실행됨 => init 컨테이너에서 network 정상상태 체크

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

출처: 쿠버네티스 공홈

• 첫번째 init container: myservice가 정상 실행되었을 때 완료
• 두번째 init container: mydb가 정상 실행되었을 때 완료

5-4. infra container

목표: infra container(pause) 이해하기

pause 컨테이너 란?

• pod의 환경을 만들어주는 컨테이너
• pod이 생성될 때 마다, 아무 동작안하는 pause라는 컨테이너가 자동으로 추가됨

비고

1. 현재 동작중인 컨테이너 알려주는 명령어
   • docker ps

5-5. static Pod(feat. kubelet daemon)

static container란?

api 서버없이, 특정 워커 노드에 있는 kubelet 데몬에 의해 직접 관리되는 컨테이너

• /etc/kubernetes/manifests(static Pod Path) 디렉토리에 k8s yaml 파일 저장하는 순간 실행됨
• 목적: api가 정해주는 워커노드가 아니라, 원하는 워커노드에서 실행시키고 싶을 때?

실행방법

• 일반적인 pod 생성과정과 다름
  • 컨트롤 플레인 api에게 요청을 보내지 않음
• 워커노드의 kubelet 데몬이 관리하는 static pod directory에서 yaml파일을 실행

5-6. Pod에 Resource 할당하기(cpu, memory requests, limits)

컨트롤플레인의 스케쥴러가 컨테이너를 실행할 워커노드를 고를 때, 어떻게 고를까?!

Pod Resource 요청 및 제한

• Resource Requests
  • 파드를 실행하기 위한 최소 리소스 양을 요청
  • ex. 최소 cpu-xxx, mem-yyy 가 보장되는 곳에 배치시켜주세요!
  • 모든 워커노드에서 이 조건을 만족하지 못하면, pending 상태가 됨
• Resource Limits
  • 파드가 사용할 수 있는 최대 리소스 양을 제한
  • memory limit을 초과해서 사용되는 파드는 종료(oom kill)되며, 다시 스케쥴링 됨
  • request없이, limit설정하면 -> request도 limit과 동일하게 자동으로 들어감

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-env
spec:
  containers:
  - name: nginx-container
    image: nginx:1.14
    ports:
    - containerPort: 80
      protocol: TCP
    env:
    - name: MYVAR
      value: "testvalue"
    resources:
      requests:
        memory: 500Mi
        cpu: 200m
      limits:
        memory: 1Gi
        cpu: 1

• 단위
  • 메모리: 1Mi == 1000Ki
  • cpu
    • 1코어 == 1000m(c)
    • 1 -> 1코어
    • 200m -> 200밀리코어 (== 1코어의 20%)

5-7. Pod 환경변수 설정과 실행 패턴

6. Controller

쿠버네티스가 제공해주는 컨트롤러 종류

1. ReplicationController
2. ReplicaSet
3. Deployment
4. DaemonSet
5. StatefulSet
6. Job
7. CronJob

각 컨트롤러마다 어떤 역할을 하는지 확인해보기!

6-1. ReplicationController 란?

Controller 설명

• 특정 애플리케이션을 실행시키는 Pod의 개수를 보장
• 쿠버야, 나 nginx웹서버 3개 실행해줘
  == kubectl create deployment webui --imgae=nginx --replicas=3
  -> 이후 3개가 잘 보장되는지 확인하는 역할

Controller의 종류

1. ReplicationController
2. ReplicaSet
3. Deployment
   • ReplicaSet의 부모 역할?
4. DaemonSet
5. StatefulSet
6. Job
   • 배치잡을 처리해주는 역할
7. CronJob
   • Job의 부모역할?

ReplicationController

출처: https://youtu.be/5X3t6VJH2vQ?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=819

• 목표

  • 요구하는 Pod의 개수를 보장하며, Pod 집합의 실행을 항상 안정적으로 유지하는 것
    • 요구하는 Pod의 개수보다 부족 -> template를 이용해 Pod 추가
    • 요구하는 Pod의 개수보다 많음 -> 최근에 생성된 Pod를 삭제

• 기본구성

  • selector: ?? 인식표 같은 개념인가?
  • replicas: 배포갯수
  • template: 추가 배포 시 참고할 정보

// Pod-Definition
apiVersion: v1
kind: Pod
metadata:
  name: rc-nginx
  labes:
    app: webui
spec:
  containers:
  - name: nginx-container
    image: nginx:1.14

// ReplicationController-Definition
apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-nginx
spec:
  replicas: 3
  selector:
    app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui //selector를 꼭 포함해야 함
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

• 특징
  • cli 명령어로 replicas다루기 쉬움
    • kubectl edit rc [rc-nginx] 해서 replicas값 수정하면, 저장하자 마자 반영됨(controller가 계속 보고있으니까!)
    • kubectl scale [rc-nginx] --replicas=[2]
  • yaml파일의 image 값을 바꾸면? 실행중인 파드에 영향x. 왜냐하면, 컨트롤러는 selector값만? 보고있는데, selector는 변함없으므로!
    • replicas가 바뀔 때는, 새로 바뀐 image대로 컨테이너가 생성됨~~

비고

1. 라벨 셀렉터를 보고, 그 라벨 셀렉터의 replicas(개수)를 보장해준다는데, 라벨 셀렉터를 본다는 것이 무슨 의미인지?
   https://youtu.be/5X3t6VJH2vQ?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=710
   -> 라벨 셀렉터는 약간 별명?같은 것인지?

6-2. ReplicaSet(ReplicationController와의 차이점은?) 쿠버네티스 pod 개수 보장

• ReplicationController 와 같은 역할하는 컨트롤러

• ReplicationController 보다 풍부한 selector 지원

  selector:
    matchLabels:
      component: redis //여기까지만 쓰면, replication controller와 동일함
    matchExpressions:
      - {key: tier, operator: In, values: [cache]}
      - {key: environment, operator: Notln, values: [dev]}

• matchExpressions 연산자

  • In: key, values지정해서, key,value가 일치하는 pod만 연결
  • NotIn: key는 일치하고, value는 일치하지 않는 pod에 연결
  • Exists: key에 맞는 label의 pod를 연결
  • DoesNotExist: key와 다른 label의 pod를 연결

비고

1. casecade=false 옵션을 넣으면, 연쇄적으로 동작하는 것들을 막아줌
   ex. replicaSet을 지우면, 속한 pod들이 모두 삭제되어야 하는데, 저 옵션이 있을 경우, rs만 삭제됨

6-3. RollingUpdate를 위한 Deployment

출처: https://youtu.be/L5LDBWrP6QU?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=93

• 목적
  • ReplicaSet을 컨트롤 해서, 파드 수를 조절 - Rolling Update & Rolling Back

apiVersion: apps/v1
kind: Deployment //롤링업데이트 기능 사용하지 않으면, replicaset과 동일함
metadata:
  name: deploy-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

롤링 업데이트란?

파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 -> 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해줌

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
  annotations:
    kubernetes.io/change-cause: version 1.15
spec:
  progressDeadlineSeconds: 600
  revisionHistoryLimit: 10
  strategy:
    rollingUpdate:
      maxSurge: 25% //replicas 의 몇 퍼센트를 롤링업데이트 시 생성할지 ex. replica가 3이면, 3+1해서 배포시 공존하는 파드는 4대까지(업데이트된거 running되면 한개 죽임)
      maxUnavailable: 25%
    type: RollingUpdate
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      labels:
        app: webui
    spec:
      containers:
      - name: web
        image: nginx:1.15
        ports:
        - containerPort: 80

• anotaion 역할
  뭐지???

명령어

1. 이전 업데이트 기록 출력

   • kubectl rollout history
   • 이렇게 이력 남기려면, 명령어 마지막에 --record 추가해야하함

2. 이미지 교체하면서 롤링업데이트

   • kubectl set image deployment [app-deploy] web=nginx:1.15 --record

3. 바로 전 단계로 롤백

   • kubectl rollout undo deployment [app-deploy]
   • undo를 할 수록, 계속 과거로 가는게 아니라, 바로 이전 단계로 가는 것임을 유의!

4. 특정 단계로 롤백

   • kubectl rollout undo deployment --to-revision=3
   • 이렇게 할경우, history에서는 3번 라인이 가장 마지막 라인으로 이동하게 됨

6-4. DaemonSet

DaemonSet

• 전체 노드에서 Pod가 한 개씩 실행되도록 보장
  • 노드 당 1개를 보장하니, replica 설정이 필요없음
• 활용 예시: 로그 수입기, 모니터링 에이전트와 같은 프로그램 실행 시 적용
• 롤링업데이트, 롤백 기능을 제공함

비고

애플리케이션(컨테이너)특성마다 컨트롤러 종류를 다르게 쓰면 좋을듯.

6-5. statefulSet

• Pod의 상태를 유지해주는 컨트롤러
  • Pod 이름 : 뒤에 있는 hash값
    
    출처: https://youtu.be/Mx3y9un1KeI?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=172
    • statefulSet은 hash값 대신, 0,1,2 ordinal하게 만들어짐
    • ex. 1번 파드가 지워지면, 1번 파드가 생성됨(어떤 노드에 생성될지는 모름! 랜덤함!)
    • ex. replicas를 줄이면, 큰번호부터 파드 삭제함
  • Pod의 볼륨(스토리지)
• 사용예시
  • 쿠버야, StatefulSet으로 nginx3개 실행해줘

6-6. Job Controller

• Pod의 성공적인 완료를 보장
  • 비정상 종료 시 다시 실행(restart)
  • 정상 종료 시 완료(end)
    • 그렇다고, 파드를 지우는건 아님. 그저 작업완료 상태!
• Batch 처리에 적합함

yaml 파일에 쓰이는 각종 key

• restartPolicy
  • OnFailure: 실패하면, <컨테이너>를 재실행해라!
  • Never: 실패하면, <파드>를 새로 생성하는 방식으로 재실행해라!(backoffLimit 과는 무관)
• backoffLimit: 재실행 시도할 횟수
• activeDeadlineSeconds: 이 정도면 충분히 실행하고 종료하겠지? 싶은 예상값(지정시간 내의 job 완료) -> 이 값이 지나면, restart 함

비고

• 쿠버네티스는 Pod를 running중인 상태로 유지(기본성질)
  • 애플리케이션이 종료되면 -> restart됨
• (궁금) 1회성 배치 처리에 유용하단건가???

6-7. CronJob

• 사용자가 원하는 시간에 JOB 실행 예약 지원
• job 컨트롤러로 실행할 어플리케이션 파드를 주기적으로 반복해서 실행.
• Linux의 cronjob의 스케줄링 기능을 job controller에 추가한 api
• 예시
  • 데이터 백업, 이메일 전송, 작업 내역 삭제

Cronjob schedule

ex. 매월 1일 아침 9시 정각에 job을 실행해줘
== 0 9 1 * * (분 시 일 월 요일)

definition

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-exam
spec:
  schedule: "* * * * *"
  startingDeadlineSeconds: 500 //500초안에 이 잡을 실행시키지 못하면, 취소
#  concurrencyPolicy: Allow // 러닝 중인 잡이 여러개여도 괜찮음
  concurrencyPolicy: Forbid // 러닝 중인 잡이 여러개이면 안됨
  jobTemplate:
    spec:
      template: //job definition과 동일
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - echo Hello; sleep 10; echo Bye
          restartPolicy: Never

7. 서비스

7-1. 쿠버네티스 service 개념과 종류

쿠버네티스 service 개념

• 동일한 서비스를 제공하는 pod 그룹의 단일 진입점을 제공
• "쿠버야 [web ui] 파드들을 하나의 ip로 묶어서 관리해줘!"
  • 파드들의 label을 기준으로 하나로 묶음(virtual ip를 만드는 것)

쿠버네티스 service 타입

• clusterIp(default)
  • pod그룹의 단일 진입점(virtual ip) 생성
• NodePort
  • clusterIp가 생성된 후 -> 모든 worker node에 외부에서 접속가능한 포트가 예약
• loadBalancer
  • 클라우드 환경이나 오픈스택 클라우드에 적용
  • LoadBalancer(따로 구축해야함)를 자동으로 프로 비전(?) 하는 기능 지원
• ExternalName(dns와 유사)
  • 외부에서 접속할 때 쓰는 도메인(?)
    • == 클러스터 안에서 사용할 도메인
  • 클러스터 도메인이 실제 외부 도메인으로 치환되어 동작

7-3. 쿠버네티스 Headless Servcie와 Kube Proxy 강좌

Headless Servcie

• ClusterIp가 없는 서비스로 단일 진입점이 필요 없을 때 사용
  • pod들의 endpoint에 dns resoloving service 지원받을 수 있도록 해줌
  • ==단일 진입점으로 묶어주긴 하는데, 별도의 ip addr은 없음
• (Service와 연결된) pod의 endpoint로 core dns에 레코드가 생성됨
• pod의 dns 주소: pod-ip-addr.namespace.pod.cluster.local

apiVersion: v1
kind: Service
metadata:
  name: headless-service
spec:
  type: ClusterIP
  clusterIP: None // 이게 none이면, headless service라는 의미
  selector:
    app: webui
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

• statefulset같이 파드 이름이 보존되는 것과 같이 사용할 때 유용함

kube-proxy

출처: https://youtu.be/ilQSgu8qt0o?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=1078

• 쿠버네티스 서비스의 backend 구현
• endpoint 연결을 위한 iptables 구성
• nodePort로의 접근과 pod연결을 구현(iptablese 구성)
  • node port번호로 listen 상태임(연결 들어오면, 맺어줌)
• 모든 노드(컨트롤 플레인+워커노드)에서 동작중인 파드임

동작방식

• userspace: 쿠버네티스 초기버전에서 운영됨(지금은 쓰이지 않음)
• iptables(default)
  • 디폴트 쿠버네티스 네트워크 모드
  • kube-proxy는 service API 요청 시 iptables rule이 생성
  • 클라이언트 연결은 kube-proxy가 받아서, iptables룰을 통해 연결
• IPVS: 리눅스 커널이 지원하는 l4 로드밸런싱 기술 이용
  • 별도의 ipvs 지원 모듈을 설정한 후 적용가능

8. 인그레스

8-1. 쿠버네티스 ingress개념과 ingress controller 설치

학습목표

1. 인그레스의 이해
2. 인그레스 컨트롤러 설치

ingress 개념

출처: https://youtu.be/y5-u4jtflic?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=563

파드, 컨트롤러, 서비스와 같은 종류의 api임
http나 https를 통해 클러스터 내부의 서비스를 외부로 노출

기능

1. service에 외부 url을 제공 (웹서비스에 유용)
2. 트래픽을 로드밸런싱
3. SSL 인증서 처리
4. virtual hosting 을 지정

종류

예시: nginx ingress controller

definition

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: marvel-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: marvel-service
          servicePort: 80
      - path: /pay
        backend:
          serviceName: pay-service
          servicePort: 80

9. 레이블과 애너테이션

• 레이블(label)이란?
• 워커 노드에 레이블 설정
• 레이블과 애너테이션
• 레이블을 이용한 카나리 배포

9-1. 쿠버네티스 label

• Node를 포함하여, pod, deployment 등 모든 리소스에 할당
• 목적: 리소스의 특성을 분류
  • selector를 이용해서 선택
• 형태: key-value 한 쌍으로 적용
  
  출처: https://youtu.be/yf5syEBAg2Y?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=618

예시

label

metadata:
  labels:
    rel: stable // 예시
    name: mainui // 예시
    envirment: dev // 예시

selector

selector:
  matchLabels:
    key: value
  matchExpressions:
    - {key: name, operator:In, values: [mainui]}
    - {key: rel, operator:NotIn, values: ["beta", "canary"]}

명령어

• rel이 beta값인 파드만 보여줘라!
  • kubectl get pods --selector rel=beta

파드 생성 with label 예시

apiVersion: v1
kind: Pod
metadata:
  name: label-pod-demo
  labels:
    name: mainui
    rel: stable
spec:
  containers:
  - name: nginx
    image: nginx:1.14
    ports:
    - containerPort: 80

9-2. 쿠버네티스 node label

학습목표: 워커노드에 label 설정

출처: https://youtu.be/1UlMwsSN45Y?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=308

필요성

• 워커노드의 스펙이 다를 때, 그 특성을 label로 설정
  • kubectl label nodes [노드이름][레이블 키]=[레이블 값]
• 노드를 선택해서, 파드를 배치할 수 있음

명령어

• 레이블 지정
  • kubectl label nodes [node1.example.com][gpu=true] [disk=ssd]

예시

특정 노드를 선택해서 파드 생성 yaml 파일

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
spec:
  nodeSelector: // 다른 노드들이 아무리 한가해도, 이 조건을 만족시키는 노드에 파드 생성됨
    gpu: "true"
    disk: ssd
  containers:
  - name: nginx
    image: nginx:1.14
    ports:
    - containerPort: 80

만약에, nodeSelector 기준에 맞는 노드가 없을경우?
-> 파드 상태가 pending 으로 유지됨

9-3. 쿠버네티스 annotation

• label과 동일하게 key-value 를 통해 리소스의 특성 기록
• 목적
  • 쿠버네티스에게 특정 정보 전달할 용도
    • 예시: deployment의 rolling update 정보 기록
    • ex. kubernates.io/change-cause: version 1.1.5 (이 버전정보가 히스토리에 기록됨)
  • 운영환경에서 관리를 위해, 필요한 정보를 기록할 용도로 사용
    • 예시: 릴리즈, 로깅, 모니터링에 필요한 정보들을 기록
    • ex.

    annotaions:
      builder: "burrito"
      buildDate: "20221110"
      imageRegistry: https://hub.docker.com/ 

definition 예시

apiVersion: v1
kind: Pod
metadata:
  name: pod-annotation
  annotations:
    builder: "burrito"
    buildDate: "20221110"
    imageRegistry: https://hub.docker.com/
spec:
  containers:
  - name: nginx
    image: nginx:1.14
    ports:
    - containerPort: 80

9-4. 쿠버네티스 Canary Deployment(label 활용 예시)

학습목표: 레이블을 이용한 카나리 배포

카나리 배포란?

• 파드를 배포(업데이트) 하는 방법
  • 블루(old) 그린(new) 업데이트
  • 카나리 업데이트
  • 롤링 업데이트
    • 기존의 pod에서 새로운 버전을 추가하고 레플리카셋을 줄이면서 점진적으로 전환하는 배포
• Canary 배포
  • 기존 버전 유지 + 일부 버전만 신규 버전으로 올림
  • 신규 버전에서 버그/이상 확인
  • 예시: 이전버전 80%, 새버전 20%와 같이 기준을 정해 새버전과 기존버전을 함께 동작시켜 전체 운영환경 모니터링, 서비스 동작 모니터링

레이블을 이용한 카나리 배포 예시

출처: https://youtu.be/u588KXtBoKU?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=406

10. 쿠버네티스 ConfigMap

학습목표

ConfigMap 이해하기

목적: 컨테이너 구성 정보를 한 곳에 모아서 관리하기

출처: https://youtu.be/xyGTvkKzrB4?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=135

전달방식

환경변수, 볼륨마운트를 통한 저장소(?)

ConfigMap 생성

kubectl create configmap [CONFIG_NAME][--from-file=source] [--from-literal=key1=value1]

출처: https://youtu.be/xyGTvkKzrB4?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=402

ConfigMap의 일부분을 적용하기

생성한 ConfigMap의 key를 pod의 컨테이너에 적용

• 수정사항이 발생하면, configmap만 바꾸고, pod재시작하면됨!

apiVersion: v1
kind: Pod
metadata:
  name: genid-stone
spec:
  containers:
  - image: smlinux/genid:env
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: ttabae-config
          key: INTERVAL 
    name: fakeid
    volumeMounts:
    - name: html
      mountPath: /webdata
  - image: nginx:1.14
    name: web-server
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
  volumes:
  - name: html
    emptyDir: {}

ConfigMap 전체를 적용하기

생성한 ConfigMap 전체 key를 pod의 컨테이너에 적용

apiVersion: v1
kind: Pod
metadata:
  name: genid-boy
spec:
  containers:
  - image: smlinux/genid:env
    envFrom:
    - configMapRef:
        name: ttabae-config
    name: fakeid
    volumeMounts:
    - name: html
      mountPath: /webdata
  - image: nginx:1.14
    name: web-server
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
  volumes:
  - name: html
    emptyDir: {}

ConfigMap을 볼륨(마운트)으로 적용하기

생성한 ConfigMap의 key를 pod의 컨테이너에 볼륨 마운트 하기

apiVersion: v1
kind: Pod
metadata:
  name: genid-volume
spec:
  containers:
  - image: smlinux/genid:env
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: ttabae-config
          key: INTERVAL
    name: fakeid-generator
    volumeMounts:
    - name: html
      mountPath: /webdata
  - image: nginx:1.14
    name: web-server
    ports:
    - containerPort: 80
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    - name: config
      mountPath: /etc/nginx/conf.d
      readOnly: true
  volumes:
  - name: html
    emptyDir: {}
  - name: config
    configMap:
      name: ttabae-config
      items:
      - key: nginx-config.conf
        path: nginx-config.conf

11. 쿠버네티스 secret

secret이란?

출처: https://youtu.be/aW2RAVnOHFY?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&t=178

• configMap: 컨테이너 구성 정보를 한 곳에 모아서 관리
• secret: 컨테이너가 사용하는 pw, auth token, ssh key와 같은 중요한 정보를 저장 + 민감한 구성정보를 base64로 인코딩해서 한 곳에 모아서 관리
• 민감하지 않은 일반 설정파일 configMap을 사용하고, 민감한 데이터는 secret을 사용
• secret 데이터 전달 방법
  • Command-lint Argument
  • Environment Variable
  • Volumn Mount

secret 만들기

kubectl create secret [Available Commands] name [flags][options]

available commands

1. docker-registry
2. generic
3. tls

secret 사용하기

정의된 secret을 pod의 컨테이너에 전달하는 방법

1. environment variable로 전달
2. command-line argument로 전달
3. volume에 secret을 사용하여, 컨테이너 디렉토리에 mount

secret 데이터 용량 제한

• secret etcd에 암호화 하지 않은 텍스트로 저장 -> secret value가 커지면, 메모리 용량을 많이 사용하게 됨
• secret의 최대 크기는 1MB