Source code modification

그냥 코드단위로 스케줄러 변경

Extender mechanism

HTTP로 추가적인 프로세스를 실행시켜 filtering과 scoring을 진행한다.

Custom Scheduler

여러개의 custom scheduler를 만들어서 pod마다 다른 scheduler를 실행시킬 수 있다.

Scheduling framework

scheduling 과정에 있는 여러 개의 plugin들을 추가/제거해 filtering과 scoring 방식을 바꿀 뿐만 아니라 pod queue에 정렬되는 기준들을 변경할 수도 있다.

Input to the scheduler from another component

Custom logic을 만들어서 affinity label등을 추가할 수 있다.

Custom Scheduler의 트렌드

초기의 custom scheduler들은 2017년에 나왔다. 걑은 종류의 자원을 두고 경쟁하는 pod들에 대해 QoS(Quality of Service) class를 제공해서 자원 할당 정도를 조정하는 것 등이 나왔다.

2019년에 나온 custom scheduler는 GPU sharing을 구현하고 utilization 정도를 올리기 위해 scheduler를 제작하였다.

2019년 이후부터는 크게 두 분류의 custom scheduler가 개발됐다. 첫 번째는 fog/edge computing을 지원해주는 custom scheduler를 개발했다. 기존의 K8s scheduler는 fog/edge의 노드들에 대한 topology를 신경쓰지 않았기 때문에 이것을 지원하기 위한 scheduler를 개발했다. 두 번째는 GPT-2나 GPT-3등의 NLP 기반 작업에서 효율성을 높이는 방향으로 custom scheduler를 개발하였다.

Classification methodology

workload 속도 최적화

• Interference and colocation : 같은 resource를 사용하는 multiple workload를 한 노드에 넣으면 resource conflict가 일어난다.

• QoS support 부족 : CPU, memory, local storage등의 resource는 scheduling시 고려되지만, network bandwidth에 대한 고려는 이루어지지 않고 있다.

• Topology-awareness : edge/fog 상에서 node들 간의 topology가 고려되지 않는 scheduling은 latency를 증가시킨다. 예를 들어 연결되는 작업을 하는 두 pod이 먼 node상에 있을 경우 통신시간이 증가한다.

• No support for co-scheduling : 연결된 작업을 하는 여러 pod의 그룹들을 scheduling할 때 동시에 하지 못하고 하나하나씩 차례로 scheduling해야 한다. 따라서 마지막 pod이 스케줄링되지 전까지 작업을 시작하지 못한다.

• No support for batch scheduling : batch scheduling이 없기 때문에 multi-priority queuing, fairness, and advanced preemption, multiple schedulers 등으로 대신하고 있다.

• No support for data locality awareness : data locality를 인식하도록 개선이 필요하다.

resource의 사용효율 증가

• Lack of real load awareness : pod이 스케줄링될 때 request만큼의 여유 resource를 가진 node로 할당되는데, 이 때 실행중인 pod의 resource 소비량은 실제 소비량이 아닌 해당 pod들의 request를 기준으로 계산된다. 따라서 실제 사용량을 기준으로 계산하면 더 효율적인 resource 사용이 가능해진다.

• GPU sharing : GPU의 할당량은 정수로밖에 지원되지 않으므로, custom scheduler를 만들어서 여러 pod들이 한 GPU를 사용할 수 있도록 custom scheduler를 개발할 수 있다.

Negative environmental impact 감소

환경을 보존하자!

Scheduler 심화

scheduler의 특징은 다음으로 나눌 수 있다.

• Objective : 앞에서 본 3개

• Target environment : cloud 환경인지, 아니면 edge/fog 환경인지 나누고, cloud라면 ML/DL 위주인지 체크한다.

• Target workloads (1) AI/ML 환경에서 training or inference (2) Serverless 환경 (3) Big data Analytics (4) Stateful apps (ex. DB) (5) Virtual network functions (6) Network intensive (7) Delay sensitive (8) Heterogeneous

• 어떤 operation을 건들지 (1) Sorting (2) Filtering (3) Scoring

• custom 방식 (1) 앞에서 본 5개

• 성능 평가 방식 (1) Real Cluster (2) Simulator (3) None

Custom Scheduler 예제

Interference & Colocation

workload들이 같은 자원을 두고 경쟁하지 못하도록 scheduling하는 것을 목표로 한다.

1. 어떤 제안자는 자원 분산을 위해 딥러닝의 강화학습을 기반으로 한 Harmony라는 모델을 제안한다. Harmony 모델은 클러스터 상태와 request resource를 입력으로 받고 pod을 알맞은 노드에 배치한다. 그 후 log로 interference 정도를 추출해 보상의 정도를 정하고 자원을 효율적으로 이용할 수 있다.

출처 - Deep Learning-based Job Placement in Distributed Machine Learning Clusters

2. 어떤 제안자는 기존처럼 딥러닝 워크로드의 GPU 사용량을 실시간으로 평가하는 대신 딥러닝 모델을 통해 정보를 추출하고 GPU의 활용률을 예측해서 보여준다.

출처 - Towards GPU Utilization Prediction for Cloud Deep Learning

Lack of support for Network QoS

1. Kubernetes에서는 network를 자원의 단위로 간주하지 않으므로 NBW guard라는 network bandwidth 관리 system를 추가한다. NBW guard는 Linux 기반의 network management tool을 사용해서 traffic을 제한한다. 즉 network bandwidth를 할당해줌으로써 pod의 traffic이 특정 수치를 넘지 않도록 조절한다.

2. Remote DMA(네트워크 상에서 사용되는 DMA)를 관여한다. pod에서 RDMA bandwidth에 대한 request와 limit을 설정하도록 한다. 그리고 한 pod에서 multiple RDMA interface가 할당될 수 있도록 한다. 이를 통해 data transfer의 bandwidth를 조절할 수 있다.

3. latency-sensitive하고 data-intensive한 edge/fog 환경에서 실시간의 network status 정보를 확인하기 위해서 network-aware-scheduler(NAS)를 개발한다. NAS 상에서 fog에 해당하는 노드는 RTT(round trip time, 패킷 왕복 시간)으로 labeling된다. 또한 available bandwidth를 설정해서 노드에서 할당 가능한 대역폭을 넘기면 filtering시키는 과정을 거친다.

Topology-awareness

edge/fog에 제한되는 내용이므로 넘어가자.

No Support for Co-scheduling

1. Serverless workload상에서는 여러 개의 pod이 스케줄링될 때 각 부분의 이미지를 가지는 pod들에 대해서(ex. replicaset등을 말하는것 같다) 노드 탐색을 반복적으로 수행하므로 overhead가 발생한다. 따라서 동일한 이미지를 가지는 pod들을 한번에 스케줄링하는 방식을 사용하면 시간이 절약된다.

2. Kubernetes의 베타 기능으로 SIG(Special Interest Group)이 있다. pod spec에서 pod이 속한 group을 지정하고 pod 그룹의 우선순위를 비교해서 ready queue에서 정렬작업을 한다.

No Support for Batch Scheduling

1. multi-tenant 클라우드 환경에서 tenant간의 fairness를 보장해야 한다. Kube-batch에서는 fairness 보장 수단이 DRF(Domain Resource Fariness)밖에 존재하지 않으므로, 저자는 Kube-sphere라는 demand-aware와 demand-DRF-aware 2개를 추가로 고려하는 custom scheduler를 제작한다. demand-aware의 경우 많은 resource를 요구하는 유저를 우선하고, demand-DRF-aware는 starvation을 막기 위해 유저의 demand와 dominant resource share를 둘다 고려한다.

2. 두가지의 scheduler를 제안한다. 첫번째는 busy hour에 사용하는, resource requirements를 기반으로 한 queue sorting을 사용해서 fragmentation 문제를 완화한다. 두번째는 GPU-intensive 작업을 위해 사용하는데, 그들의 waiting time과 estimated running time을 잘 고려해서 priority를 동적으로 조절한다.

3. Kube-batch는 AL/ML 등의 데이터와 CPU 작업이 많이 필요한 작업들을 위해 batch 스케줄링을 목료로 한다. Kube-batch는 다양한 우선순위 class들과 gang scheduling을 지원하며, Kubeflow나 Volcano등에서 사용한다. Apache Yunikorn는 YARN을 같이 사용해서 batch-scheduling을 지원하는 tool이다. stateless workload + statedful service같은 혼합된 workload를 사용가능하게 할 수 있다. hierarchical resource queues, multi-policy job queuing를 사용해서 fairness를 개선하는 한편 scheduling throughput을 향상시킬 수 있다.

gang scheduling이란? 한 process의 여러 thread들을 따로따로 CPU에 실행시킴. pararell programming에서 사용 가능하다.

No support for Data locality Awareness

Lack of Real load awareness

pod을 scheduling할 때 reqeust값이 아닌 실제 사용량을 기반으로 scheduling plan을 만든다.

1. edge-computing 환경에서 실시간의 resource consumption을 기반으로 scheduling한다. 실시간의 scheduling 정보(ex. load, temperature, liveness)등을 node로부터 모은 후 node score를 계산해서 schdeuling한다.

2. modified PSO(particle swarm optimization) 알고리즘을 사용해 scheduling한다. node의 사용량을 CPU와 memory 뿐만 아니라 affinity를 가지고 계산한다.

3. IBM에서 개발된 Trimaran이라는 load-aware scheduler plugin이 있다. 이 plugin은 pod resource의 request와 실제 사용량 사이의 불일치를 탐지하는데, 이것에 TargetLoadPacking와 LoadVariationRiskBalancing라는 두 가지 plugin을 사용한다. TargetLoadPacking는 각 node에서 실제 resource 사용량을 기준으로 점수를 매긴다. LoadVariationRiskBalancing는 자원 사용의 평균과 표준편차를 구해서 점수를 매긴다.

4. Intel에서는 실시간의 telemetry 정보를 이용하는 TAS(Telemetry-aware scheduler)를 사용한다. 이 scheduler에서는 extender mechanism을 사용해 node의 power, CPU, memory등의 사용량을 체크한다.

GPU Sharing

1. GAIA는 GPU sharing을 제안한 scheduler이다. GPU cluster를 communication cost를 기반으로 tree 구조로 설계하고 얼마나 사용중인지의 상태를 표시한다. GAIA에서는 이 tree 구조에서 얼마나 GPU를 할당해줄 것인지 확인한다. 그리고 GAIA에서는 device plugin을 사용해서 GPU를 fractional한 virtual GPU들로 나눌 수 있다.

2. pod이 필요한 GPU 사용량보다 적은 GPU를 가진 node은 filtering한다. GPU 할당을 CPU와 memory처럼 하기 위해 두 개의 Custom Resource를 개발하는데, RESOURCE-MEM은 사용 가능한 VRAM의 크기이고 RESOURCE-COUNT는 사용 가능한 GPU의 수이다. 그리고 NVIDIA device plugin을 사용해서 GPU를 kubelet에서 인지하도록 한다.

3. KubeShare라는 프레임워크로 GPU sharing을 제안한다. SharePod이라는 Custom Resource를 제안하고, vGPU라는 custom shared device를 붙인다. 그리고 vGPU를 적절하게 continaer에 붙여주는 KubeShare-Sched와 vGPU pool을 관리하는 KubeShare-DevMgr라는 Custom controller를 만든다.

4. 어떤 작업이 CPU나 GPU에서 둘 다 수행 가능할 경우, CPU를 할당받을 때와 GPU를 할당받을 때의 예상 완료 시간을 비교해 더 나은 쪽으로 자원을 할당해준다.

Specific Contributions - etc

새로운 알고리즘 사용하기

1. SpeCon이라는 scheduler는 DL training의 application specefic의 효율성을 높이기 위해 제안되었다. DL 작업의 여러 단계들은 각각 자원의 필요량이 차이가 난다. 따라서 DL 작업을 progressing, watching, converge 3분류로 나눈다. 작업 속도가 느린 단계에서 리소스를 빼와서 작업 속도가 빠른 단계에 집중시킨다. 이로부터 DL 수행시간을 줄일 수 있다.

2. Prediction을 사용해서 CPU노드와 GPU노드 모두에 대한 작업 소요시간을 예상한다. Prediction은 instrcution수, floating point 계산수, 사용하는 resource량 등으로 예측하고, workload들의 우선순위를 조절하고 더 적절한 노드에 할당한다.

Summary

Annotation, Label, Extended Resource, CRD, Device Plugin을 추가해서 스케줄러를 확장할 수 있다.

기본 Scheduler의 작동방식

Scheduler가 pod을 배치하는 것은 크게 Scheduling cycle, Binding cycle로 나뉜다. cycle 안의 각각의 단계들은 plugin에 의해 동작한다.

PreEnqueue

scheduling되려는 pod이 가장 처음 들어오는 queue이다. 안에 있는 모든 PreEnqueue Plugin이 Success를 return하면 pod들이 active queue로 들어가기 시작한다.

Scheduling cycle

pod에 적합한 node를 선택하는 과정이다. 기본적으로 아래의 순서대로 진행된다.

PreFilter

pod에 대한 정보를 전처리하거나, pod이 만족해야 하는 필수사항을 체크한다. 만족하지 못하면 pod을 unscheduled로 만든다.

Filter

여러 개의 filter를 통해 pod에 적합하지 않은 node를 제거한다. Taint와 Tolerence가 여기서 적용된다. node가 모두 filter를 통과하지 않으면 postFilter 단계로 넘어간다.

PostFilter

pod이 실행 가능한 node가 모두 filtering되었을 때 pod pre-emption등의 작업을 거쳐 node가 조건을 만족하도록 바꿔준다. 이래도 해결되지 않을 경우 pod을 unscheduled로 만든다.

Score

filtering되지 않은 node들에 대해 적합도를 매긴다. NodeAffinity가 여기서 적용된다. 적합도는 여러 기준을 사용할 수 있다. 그 후 적합도가 가장 높은 node를 선택한다.

Reserve

race condition등을 방지하기 위해 pod에서 필요한 resource들을 예약해 둔다.

Permit

Binding cycle에 들어가기 전에 대기할 수 있다.

Binding cycle

pod를 실제로 node에 바인딩하는 단계이다.

Custom scheduler

기본 scheduler에서 기본적으로 제공하는 plugin들은 여기. 여기서 몇 가지의 plugin제거하거나 custom plugin을 추가해서 custom scheduler를 만들 수 있다.

예를 들어 Scoring 단계에서 custom plugin을 적용해 custom resource에 대한 가중치를 추가할 수 있다.

적용하는 법

다음과 같이 Custom Plugin을 만들 수 있다.

type Plugin interface {
    Name() string
}

type QueueSortPlugin interface {
    Plugin
    Less(*v1.pod, *v1.pod) bool
}

type PreFilterPlugin interface {
    Plugin
    PreFilter(context.Context, *framework.CycleState, *v1.pod) error
}

Custom Plugin 또는 Kubernetes에서 배포하는 확장 플러그인을 적용하려면 다음의 yaml 파일을 작성하면 된다. 예시에서는 score 단계에서 사용할 plugin중 PodTopologySpread plugin을 비활성화하고 custom plugin A, B를 추가하였다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

또는 다음과 같이 하면 MyPlugin이 적용 가능한 익스텐션 포인트들에 한번에 적용된다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: non-multipoint-scheduler
    plugins:
      multiPoint:
        enabled:
        - name: 'MyPlugin'
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

이렇게 만들어진 custom scheduler와 기본 scheduler를 같이 사용하고 싶다면 다음과 같이 한다.

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

출처

https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/

https://kubernetes.io/ko/docs/reference/scheduling/config/

Taints

node에 pod이 scheduling되지 않도록 설정한다. control plane의 master node는 기본적으로 이 설정이 적용되어 있다. Taint의 effect는 다음 3가지가 있다. NoSchedule: Schedule 제한 PreferNoSchedule: Schedule 안하도록 권장 NoExecute: 이미 Schedule되었을 경우 preemption

다음과 같이 taint를 추가할 수 있다.

kubectl taint nodes node1 key1=value1:NoSchedule

그리고 다음과 같이 taint를 제거할 수 있다.

kubectl taint nodes node1 key1=value1:NoSchedule-

Tolerations

node의 taint를 무시하고 scheduling되도록 설정한다. Taint의 operator는 다음과 같이 2개가 있다. Equal: key, value가 겹칠 경우 적용 Exist: key가 겹칠 경우 적용 특수한 케이스로 Exist에 키가 비어있을 경우 모든 Taint를 무시한다.

다음과 같이 toleration을 추가할 수 있다.

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

Node affinity

taint와 반대로 pod을 해당 node에 배치하도록 한다.

다음과 같이 하면 조건을 만족하는 node에만 스케줄링된다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd            
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

필드 설명은 다음과 같다. requiredDuringScheduling: pod이 node에 반드시 배치되어야 한다. ...IgnoredDuringExecution: 이미 실행되고 있는 pod의 경우 pre-emption하지 않는다. nodeSelectorTerms: affinity의 조건을 지정한다. 여기서는 ssd를 사용하는 label을 선호한다는 뜻이다.

다음과 같이 하면 조건을 만족하는 node에 우선순위를 높인다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

필드 설명은 다음과 같다. preferredDuringScheduling...: pod이 node에 배치되도록 권장한다. preference: affinity의 조건을 지정한다.

또한 weight를 지정할 수 있는데, 여러 조건들이 있을 때 우선순위 반영 비율을 정하는 것이다.

Node anti-affinity

반대로 pod이 해당 node에 선호되지 않도록 할 수 있다. Taint와의 차이점은, pod이 현재 배치되어 있는 정보도 고려할 수 있다. 예를 들어 이미 같은 pod이 들어간 node에 scheduling되지 않도록 권장할 수 있다.

podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

출처

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#%EC%BB%A8%EB%94%94%EC%85%98-condition-%EC%9D%84-%EA%B8%B0%EC%A4%80%EC%9C%BC%EB%A1%9C-%EB%85%B8%EB%93%9C-%ED%85%8C%EC%9D%B8%ED%8A%B8%ED%95%98%EA%B8%B0

https://kubernetes.io/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/

https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity

HPA(Horizontal Pod Autoscaling)은 3단계로 나뉘어진다.

Pod metrics obtaining

각 node의 Kubelet에 있는 cAdvisor에서 pod metrics와 node metrics를 수집한다. 수집한 metrics는 cluster 단위에 있는 Heapster가 통합한다. HPA가 REST API로 query를 보내어 가져온다.

Pod, node -> cAdvisor -> Heapster -> HPA

Caluating the number of pods

가져온 metrics를 가지고 pod이 얼마나 필요한지 계산한다. pod을 얼마나 늘려야 desired CPU utilization, QPS에 도달하는지 간단하게 알아볼 수 있다.

pod 수 = ceil[현재 pod 수 * ( current metric / desired metric )]

Ex) Pod 1, 2, 3에서 CPU 사용량이 각각 60%, 70%, 80%라고 하자. CPU 사용량을 50%로 맞추고 싶다면 ceil[(60 + 70 + 80) / 50] = 5이다. 그러면 Pod당 평균 사용량은 (60 + 70 + 80) / 5 = 42%가 된다.

pod의 ready 상태등의 문제로 인한 누락된 metric이 있는 경우, pod updating이 적게 일어나도록 예측한다. 위의 예시에서 Pod 4의 metric이 누락됐다면, scale up을 최소화하기 위해 Pod 4는 0%의 CPU utilization값을 가진다고 가정한다.

Updating the number of Pod

앞의 예시에서 Pod의 현재 개수는 3이고 필요한 pod의 개수는 5이므로 pod을 2개 추가한다. 2개의 pod을 추가해달라는 요청을 워크로드 리소스(Deployments, Statefulsets, ...)에게 보낸다.

구현 예제

다음은 HPA를 정의하는 yaml이다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:                // scaling하려는 워크로드 리소스
    apiVersion: apps/v1            
    kind: Deployment
    name: php-apache
  minReplicas: 1                // 최소, 최대 replica 개수
  maxReplicas: 10
  metrics:                        // desired state
  - type: Resource                // 여기에선 CPU 사용량 50%를 목표로 함
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
      current:
        averageUtilization: 0
        averageValue: 0

또한 이렇게 간단하게 만들 수도 있다.

 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

HPA based on others

Memory based Autoscaling

Kubernetes 1.8에 소개되었는데, memory는 scaling up시 기존 pod들의 memory release가 일어나야 하므로, 더 구현하기 어렵다. 관련자료를 찾아보려고 하는데 보이지 않는다..

Pod based Autoscaling

Pod based autoscaling을 하기 위해 기준이 되는 resource를 정의해야 한다. 이 경우Utilization 대신 QPS(Query per second, 초당 요청량)이나 packets-per-second등을 사용한다. 마찬가지로 다음과 같이 정의하면 된다.

spec:
 metrics:
 - type: Pods
 resource:
 metricName: qps
 targetAverageValue: 100

Object based Autoscaling

동일한 namespace 내의 어떤 Object를 이용해 기준 resource를 정의한다. Object based Autoscaling의 경우 기존과 달리 모든 pod에서 metric을 가져오는 게 아니라, 하나의 single object만에서 metric을 가져와 계산한다.

type: Object
object:
  metric:
    name: requests-per-second
  describedObject:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    name: main-route
  target:
    type: Value
    value: 2k

External resource based autoscaling

외부에서 가져온 다른 리소스를 기반으로 autoscaling할 수도 있다. 다음 예제의 경우 30개의 message queue(미해결된 요청 큐)당 하나씩 pod을 추가하는 작성법이다.

- type: External
  external:
    metric:
      name: queue_messages_ready
      selector:
        matchLabels:
          queue: "worker_tasks"
    target:
      type: AverageValue
      averageValue: 30

VPA (Vertical pod autoscaling)

request와 limit을 늘리는 방법을 적어놓았다. 여기에서 resizing 항목으로 가면 적용할 수 있다.

출처

Kubernetes in Action

https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

pod이 resource마다 request를 지정하면, kube-scheduler는 request만큼의 여유공간이 존재하는 node에 스케줄링한다. 만약 해당하는 node가 없다면 스케줄하지 않고 Event를 발생시킨다.

scheduler의 스케줄링 방식으로는 가볍게 2가지가 있다. LeastRequestedPriority: 자원 여유 많은 node에 스케줄링 MostRequestedPriority: 자원 여유 적은 node에 스케줄링

request 필드는 pod들 간의 우선순위도 담당한다. Pod A의 CPU request가 1이고 Pod B의 CPU request가 3일 경우, 한 노드 안에서 Pod A와 Pod B의 작업 수행시간은 1:3으로 주어진다.

Qos

node에 자원이 과도하게 사용될 경우 pod을 강제 종료시키는데, 이 때 종료시킬 pod의 우선순위를 세 그룹으로 나눈다. 그룹은 다음과 같다.

BestEffort (lowest) pod에 따로 request나 limit을 걸어두기 않았을 경우 분류되는 그룹이다.

Burstable request < limit으로 명시될 경우 분류되는 그룹이다.

Guaranteed (highest) 모든 resource에 대해 request == limit일 경우 분류되는 그룹이다.

간단히 말하면 request / limit이 작은 순서대로 pod를 preemption한다.

Limits

limit을 지정하면 kubelet이 해당 limit을 container runtime에 전달한다. container runtime은 해당 리소스만큼 격리한 후 프로세스가 제한을 초과하는지 감시한다. 프로세스가 더 많은 자원을 요청할 경우 OOM(Out of Memory) 상태롤 출력하고 종료시킨다.

*ResourceQuota

limit은 또한 namespace 단위로 걸 수도 있는데, 이 때 ResourceQuota를 사용한다. namespace별로 resource 뿐만 아니라 requests.storage 또는 persistentvolumeclaims 등을 정의해서 Volume 등 다양한 resource에 제한을 걸 수 있다.

apiVersion: v1
kind: ResourceQuota
metadata:
 name: objects
spec:
 hard:
 pods: 10
 replicationcontrollers: 5
 secrets: 10
 configmaps: 10
 persistentvolumeclaims: 4
 services: 5
 services.loadbalancers: 1
 services.nodeports: 2
 ssd.storageclass.storage.k8s.io/persistentvolumeclaims: 2 

적용 방법

spec.containers[].resources 필드에서 limits와 requests를 설정할 수 있다. 정의하는 자원은 보통 cpu / memory / hugepages-<size> / ephemeral-storage 가 있다.

hugepage) CPU가 사용하는 메모리가 있는 RAM의 부분 (운영체제) ephemeral-storage) 캐싱, 로그등에 사용되는 RAM으로 지원되는 임시공간

아래는 yaml 적용 예제이다.

...
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Extended Resource

node level

node level로 extended resource가 만들어지면 cluster 운영자는 API server에 HTTP request를 보내서 node별로 사용량을 정할 수 있다. 예를 들어 GPU resource를 추가로 정의해 실행하는 GPU 개수 등을 지정할 수 있다.

cluster level

scheduler extender에 의해 관리된다.

Extended resource consumption

scheduler가 resource accounting 방식을 사용하여 기존 자원처럼 스케줄링 시 resource 여유공간을 넘기지 않도록 감시한다.

pod 차원에서는 일반적인 resource처럼 정의하면 된다. (예제에서 example.com/foo)

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        example.com/foo: 1
      limits:
        example.com/foo: 1

Resource resizing

Kubernetes의 1.27에 추가된 기능으로 기존에 immutable했던 request를 변경할 수 있는 기능이다. spec.containers[].resizePolicy에서 resizing 시 어떻게 할지 정의 가능하다. (기본은 NotRequired)

spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    ...

NotRequired : container running 중에 자원 추가 RestartContainer : 재시작 후 더 많은 자원으로 교체

  아래와 같은 명령어를 입력하여 resize가 가능하다.

kubectl -n {namespaceName} patch pod {podName} --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}

출처

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/

Kubernetes_in_Action

Service object

Kubernetes에서는 Service object를 사용하여 pod을 여러개 복제하고, 유저가 여러 pod들을 하나의 IP로 연결하도록 통합시킨다. 또한 여러 pod들이 Flat network이라는 공간에서 서로 통신한다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Workload Management API

Replicaset

Pod의 복제본 수를 지정해놓고, pod가 종료되면 그만큼의 pod을 새로 할당해주고 pod이 너무 많아지면 pod을 죽여서 개수를 유지한다.

각 pod마다 label을 두고 replicaset object에는 label selector를 두어 자기 관할인 pod만 지정할 수 있다. 또한 pod은 해당 replicaset이 소유한 것으로 취급된다.

다음과 같이 선언한다.

// rs.kiada.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

replicaset controller

replicaset과 그 아래 있는 pod을 관리하며, 관리 객체들의 state의 변경시 알맞게 조절해준다. 예를 들어 pod이 종료되어 명세된 개수보다 적어지면 pod을 다시 생성한다.

다음과 같이 replica의 수를 늘리거나 줄일 수 있다.

$ kubectl scale rs kiada --replicas 6
replicaset.apps/kiada scaled

replica의 수를 줄일 경우 가장 지워도 되는 pod부터 선택해서 제거한다.

pod의 label을 바꾸면 해당 replicaset controller의 통제를 벗어날 수 있다.

Deployment

application의 desired state를 정의하여 상태를 조절한다. 선언시에 replicaSet을 이용하여 pod의 개수를 정의할 수 있다.

다음과 같이 선언할 수 있다.

// deploy.kiada.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
 ...

pod updating in deployment

pod을 update할 때, deployment object에서는 rolling update라는 것을 지원한다. pod을 모두 한번에 멈춰버리면 서버가 다운되므로, pod을 천천히 하나씩 종료하고 업데이트한다.

다음과 같이 선언할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
   name: nginx
spec:
   strategy:
   type: RollingUpdate
   rollingUpdate: 
   maxSurge: 0 
   maxUnavailable: 1 
   minReadySeconds: 10
   replicas: 3
   selector:

maxSurge, maxUnavailable 두 필드가 중요하다. maxSurge: update중 원래 size를 초과하여 pod를 생성할 수 있는 최대 개수 maxUnavailable: update중 실행 가능하지 않은 pod의 최대 개수

maxSurge: 0, maxUnavailable: 1

maxSurge: 1, maxUnavailable: 0

그 외에도 여러 update strategy도 있는데 간단한 설명은 다음과 같다. 더 궁금하면 나중에 찾아보자.

Recreate: service의 일시적인 중단을 무시하고 pod을 모두 동시에 업데이트한다. Canary: 적은 수의 canary pod만 남겨두고 모두 동시에 업데이트한다. A/B testing: 두 종류의 deployment를 만들고, Ingress object를 만들어 유저 특징별로 어떤 deployment에 들어갈 것인지 결정하고 redirect한다. Blue/Green: 기존에 pod들(blue label)로 서비스하면서 새로운 pod들(green label)을 만든다. 다 완성되면 선택하는 label을 바꿔서 새로운 pod들로 연결한다. Shadowing: 새 버전이 정상적으로 작동할지 확신이 없을 때, 새 버전을 먼저 만들어 놓고 Ingress object를 만들어 traffic을 기존 버전과 새 버전에게 모두 전달한다. 새 버전의 결과는 test용도로만 쓰고 버린다.

StatefulSet

상태를 저장해야 하는 application(ex. DB)를 배포하기 위해 존재한다.

Statefulset은 각 pod마다 지정된 ID와 Persistent Volume, 그리고 안정적인 IP address를 가진다. 즉 pod의 순서와 고유성을 보장한다.

다음과 같이 선언할 수 있다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # .spec.template.metadata.labels 와 일치해야 한다
  serviceName: "nginx"
  replicas: 3 # 기본값은 1
  minReadySeconds: 10 # 기본값은 0
  template:
    metadata:
      labels:
        app: nginx # .spec.selector.matchLabels 와 일치해야 한다
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

StatefulSet의 세부기능은 나중에 추가로 봐야겠다...

DaemonSet

K8s의 모든 worker node에서 단 하나의 해당 pod을 실행하도록 한다. system 레벨의 서비스를 제공하는 application(ex. 로그, device plugin)에 주로 사용한다. 예를 들어서 Kube proxy component는 kube-system namespace를 가지고 DaemonSet으로 배포된다.

또는 node selecter를 통해 꼭 모든 node가 아니라 특정 조건을 만족하는 node에만 pod을 scheduling할 수 있다.

node selecter는 이렇게 정의할 수 있다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
   name: demo
   labels:
     app: demo
spec:
   selector:
     matchLabels:
       app: demo
   template:
     metadata:
       labels:
         app: demo
     spec:
       nodeSelector: 
         gpu: cuda 
       containers:
       - name: demo
         image: busybox
         command:
         - sleep
         - infinity

해당하는 node에는 다음과 같이 선언한다.

 $ kubectl label node kind-worker2 gpu=cuda

DaemonSet 또한 label selector를 가지고 label에 맞는 pod만 관리한다.

DaemonSet의 선언은 다음과 같다.

apiVersion: apps/v1 
kind: DaemonSet 
metadata:
     name: demo 
spec:
   selector: 
     matchLabels: 
         app: demo 
   template: 
     metadata: 
       labels: 
            app: demo 
     spec: 
       containers: 
       - name: demo 
            image: busybox 
            command: 
            - sleep 
            - infinity 

DaemonSet은 status를 가지고 있는데, 확인하려면 다음과 같다. 각 status가 의미하는 것은 너무 자명하므로 생략한다.

$ kubectl get ds demo -o yaml
...
status:
 currentNumberScheduled: 2
 desiredNumberScheduled: 2
 numberAvailable: 2
 numberMisscheduled: 0
 numberReady: 2
 updatedNumberScheduled: 2

DaemonSet만의 기능

container에게 system상의(OS kernel) 접근 권한이나 node의 filesystem이나 network등의 접근 권한을 받을 수 있다.

DaemonSet pod과의 통신

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: node-agent
 ...
spec:
 template:
   spec:
     containers:
     - name: node-agent
       image: luksa/node-agent:0.1
       args: 
       - --listen-address 
       - :80 
       ...
       ports: 
       - name: http
         containerPort: 80 
         hostPort: 11559 

이렇게 하면 각 node의 pod에서는 port 11559로 접근시 port 80에서 듣고 있는 DaemonSet pod으로 전해진다.

이것도 자세한건 나중에...

Job, CronJob

Job은 특수한 작업을 진행하는 동안만 pod을 유지시키고 이후에 pod을 종료하는 리소스이다. CronJob은 주기적으로 Job을 실행시키는 리소스로, 주로 n분 단위 시스템 감시 & 자동 업데이트 등에 사용된다.

Kubernetes는 이상적으로 어떤 환경에서도 실행과 배포가 가능해야 한다. 따라서 클라우드 스토리지의 실행 환경이나 파일 절대주소등을 넣지 않고도 사용할 방법이 필요하다.

--> PersistentVolume을 사용하자!

PersistentVolume 구조

Persistent Volume

network storage와 pod 사이의 중간과정을 만들어주어 Persistent Volume object에서 pod의 데이터들을 저장한다.

PV에 데이터가 있으므로 pod이 변경돼도 데이터를 보관할 수 있다.

Persistent Volume Claim

pod에서 Persistent volume의 데이터가 필요할 경우 PVC를 통해서 exclusive하게 데이터를 읽을 권한을 받는다.

PVC를 이용해서 접근하므로 Persistent Volume의 세부 저장환경에 구애받지 않고 PV의 이름만으로 연결해서 데이터를 가져온다.

DB의 운영자가 세부 실행환경을 맞추어 Persistent Volume을 설계하고, 이용자는 이것의 고려 없이 자유롭게 application의 데이터를 저장할 수 있다.

Access mode

ReadWriteOnce: 하나의 node에서 RW로 마운트 가능 ReadOnlyMany: 다수의 node에서 읽기 전용으로 마운트 가능 ReadWriteMany: 다수의 node에서 RW로 마운트 가능 ReadWriteOncePod: 노드의 단일 pod에서 RW로 마운트 가능

Dynamic provisioning

정적 provisioning의 단점

물리적 volume을 연결한 이후에 PersistentVolume object를 새로 만들어 주어야 하므로, 물리적 volume이 바인딩되고 해제될 때마다 해당 volume에 대한 PersistentVolume object를 계속 생산/삭제 해주어야함 -> volume의 수가 많아질수록 Kubernetes의 자동화에 악영향

To solve -> dynamic provisioning

우선 cluster admin이 storage class에 따라 PV Provisioner를 만든다. 유저가 PVC object를 먼저 만들면, cluster admin이 요청을 받아 PV Provisioner로부터 적합한 PV를 제공해준다. 제공된 PV와 PVC를 연결하는 것이다.

주의) cluster admin이 cloud같은 외부서버일 경우 Provisioner는 이미 구현되어 있지만, on-premise일 경우 custom provisioner를 직접 만들어줘야 한다.

Dynamic provisioning의 lifecycle

위에서 설명했던 내용과 같다. 유저가 PVC를 생성하면 PV Provisioner가 비동기적으로 PV를 만들어 준 후 바인딩한다.

Node-local persistent volume

네트워크 스토리지말고 로컬 스토리지의 DB들을 이용하면 접근 속도를 향상시킬 수 있다. 이전 장의 Hostpath 볼륨과 다른 점은 다음과 같다.

1. hostpath 볼륨은 pod이 다른 node로 rescheduling될 경우 해당 node 권한에 따라 데이터 접근이 안될 수 있다. 그러나 node-local PV의 경우 scheduler 차원에서 PV의 node별 접근권한을 확인해 적절한 node로 pod을 보낼 수 있다.
2. PV는 cluster manager에 의해 관리되므로 보안상 더 안전하다.

Volume이란?

container들이 파일시스템을 사용하도록 마운팅할 수 있는 저장공간

Volumn은 pod에 마운팅되고 pod과 같은 수명을 갖는다. 따라서 container가 재시작되어도 volumn의 정보는 그대로 남기 때문에 다시 가져와서 작업하면 된다.

물론 container가 crash되어 종료된 후 restart시 volume의 모든 정보를 다시 가져오면 또 crash날 확률이 높으므로 가져올 정보는 구분하자.

하나의 container에서 여러 개의 Volume에 마운트할 수 있다.

또는 r/w 권한을 부여하여 한 volume을 통해 container들끼리 데이터를 주고받을 수 있다.

External Storage에 Volume 마운트

pod에 한정된 Volume을 로컬 파일시스템이나 등의 외부 네트워크 저장소등과 연결해서 데이터를 주고받을 수 있다.

External storage 또한 여러 pod에서 동시에 접근할 수 있다.

Volume 유형

여러 유형이 있어서 더 많은 건 그때그때 확인해야겠지만, 중요한 것만 간단하게 써보려고 한다.

emptyDir

가장 간단한 Volume 형태로, 외부에서 마운트하지 않고 pod이 시작될 때 생성되어 pod의 lifecycle동안 데이터를 저장한다.

주로 container가 재시작되어도 데이터가 보존되어 있어야 하거나, 두 container가 서로 데이터를 공유할 때 사용한다.

gcePersistentDisk, awsElasticBlockStore, ...

클라우드 스토리지를 pod에 마운트할 때 사용한다. 여러 pod에서 사용할 수 있다는 장점이 있다.

주의사항은 cluster가 어떤 환경에서 실행되느냐에 따라 사용할 수 있는 저장소가 달라진다.

hostPath

node의 파일 시스템에서 pod로 마운트할 때 사용한다.

pod이 항상 동일한 node에서 실행되도록 보장되는건 아니기 때문에, pod이 다른 node로 rescheduled되면 데이터에 접근할 수 없는 위험이 있다.

일반적으로 hostPath 볼륨은 노드의 파일 시스템에서 읽거나 쓰는 파일이 필요한 경우에 사용된다. 예를 들어, 시스템 수준의 로그와 같이 노드에서 실행되는 프로세스가 읽거나 생성하는 파일에 대한 것이다.

configMap, secret, ... -

특수한 Volume 형태로, Kubernetes 객체에 대한 정보를 파일을 통해 볼 수 있는 볼륨이다.

csi

Container Storage Interface로 자신만의 저장소 드라이버를 만들어서 연결 가능한 볼륨

persistentVolumeClaim

외부 저장소를 pod으로 가져올 때 사용한다. 다음 장에서 자세히 설명한다.

container의 lifecycle

container가 생성된 이후부터 작업을 마치고 종료될 때까지의 state의 순서이다.

적당히 그림보고 알아듣자.

contiainer의 lifecycle은 다음과 같이 알아낸다.

$ kubectl describe po kiada
...
Containers:
 kiada:
 Container ID: docker://c64944a684d57faacfced0be1af44686...
 Image: luksa/kiada:0.1
 Image ID: docker-pullable://luksa/kiada@sha256:3f28...
 Port: 8080/TCP
 Host Port: 0/TCP
 State: Running 
 Started: Sun, 02 Feb 2020 12:43:03 +0100 
 Ready: True 
 Restart Count: 0 
 Environment: <none>
...

Container auto-restart policy

container는 기본적으로 종료되었을때 성공/실패 여부에 관계없이 자동재시작된다. 해당 사항은 pod의 spec의 restartPolicy에 적혀 있다. 기본은 Always이다.

Container가 재시작될 시 처음은 바로 시작하지만, 그 이후엔 시간간격을 10s, 20s, 40s, ..., 300s (max)식으로 시간간격을 늘려서 시작한다.

재시작된 이유를 보려면 다음과 같이 하면 된다.

$ kubectl get po kiada-ssl -o json | jq .status.containerStatuses
...
"state": {
 "waiting": {
 "message": "back-off 40s restarting failed container=envoy ...",
 "reason": "CrashLoopBackOff"

liveness probe

container가 살아있는지 확인은 어떻게 할까? 정상적으로 종료되거나 에러를 방출하면 알아낼 수 있지만, 무한루프나 과부하됐을 때는 알아낼 방법이 없다.

이를 해결하기 위해 Kubernetes는 container에 지속적으로 query를 날려 응답을 체크한다. 이것을 liveness probe라고 한다.

liveness probe에는 HTTP GET, TCP 연결, exec 실행의 3가지의 request 요청 방식이 있다. 세부적인 작동방식은 다음과 같다.

우선 container 실행되고 InitialDelatSeconds만큼 기다림 -> periodSeconds 주기로 request 보냄 -> timeoutSeconds만큼 응답 없을 시 failure로 취급 -> failureThreshold만큼 실패하면 container 종료

startup probe

liveness probe가 실행되기 전에 container가 제대로 시작했는지 알아보는 것으로, 실패하면 container를 종료시키고 성공하면 liveness probe단계로 넘어간다.

Post-start & Pre-stop hook

container가 시작된 직후나 종료되기 직전 따로 작업을 실행시킬 수 있는데, 이를 각각 post-start hook, pre-stop hook 이라고 한다.

이것을 이용해서 각각 시작하기 전 파일들 받아오기, container 정상종료를 수행할 수 있다.

pod의 lifecycle

pod도 container와 마찬가지로 lifecycle를 가진다.

1. Pending: pod이 처음 만들어 진 직후의 상태
2. Running: node에서 image를 받고 pod를 할당할 때 running state로 넘어간다.
3. Succeeded: pod가 모든 작업을 수행하고 성공적으로 종료되었을 때
4. Failed: pod안의 어떤 container가 에러를 띄웠을 때
5. Unknown: kubelet이 알수없는 이유로 API서버에 리포트를 보내고 있지 않을 때

  pod의 phase는 다음 명령어로 볼 수 있다.

$ kubectl get po kiada -o yaml | grep phase
phase: Running

pod의 conditions

Pod이 어떤 condition들을 만족했는지 보여주는 지표이다.

PodScheduled: pod이 node에 할당되었는지 여부 Initialized: pod의 Initial container가 성공적으로 작동했는지 ContainersReady: pod 안의 모든 container가 ready 상태인지 Ready: pod이 모든 실행준비를 끝냈는지

  pop의 condition은 다음 명령어로 볼 수 있다.

$ kubectl describe po kiada
...
Conditions:
 Type Status
 Initialized True 
 Ready True 
 ContainersReady True 
 PodScheduled True 
...

pod의 stage

pod에는 3가지의 stage가 있다.

initialization stage

init container image를 node에 받아오고 pod의 init container들이 실행시키는 단계이다.

image를 받아오면 첫번째 init node부터 차례로 실행시킨다. 중간에 실패할 경우 재시작하지 않으면 pod은 error 상태가 된다.

run stage

마찬가지로 container별로 image를 node에 받아오고 container들을 실행한다.

container가 종료될 때 container에서는 종료 로직을 실행하고 TERM 시그널을 보낸다. 일정시간이 지나도 종료되지 않으면 강제로 종료한다.

termination stage

pod을 제거할때 발생하는 단계로, 안에 있는 모든 노드에 delete signal를 보낸다. 마찬가지로 container의 종료를 기다리고, 종료되지 않으면 강제로 종료한다.

Summary

앞에서 알아본 container와 pod의 lifecycle를 요약하면 다음과 같다.

Remind Pods

pod이란 Container들을 여러 개 모아 한꺼번에 실행시키는 집합으로, 한 pod의 구성 container들은 모두 같은 node에 담겨 있다.

pod을 사용하는 이유? -> 여러 프로세스를 사용하기 위해서

한 container 안에 여러 프로세스를 실행시키지 않고 프로세스별로 container를 분할하는 이유? -> container 자체가 하나의 프로세스만을 위해 디자인됨. container 안의 프로세스가 여러개 있어도 구분 X

pod를 사용함으로써 각각의 프로세스가 container 안에서 독립적으로 실행할 수 있다. 또한 같은 namespace들을 공유함으로써 프로세스끼리 통신을 단일 컴퓨터 안에서처럼 가능하게 한다.

  하나의 pod 안에는 하나의 application을 넣는 것을 권장한다. why?) pod의 단위별로 node에 배치되고 horizontal scaling이 일어나기 때문

sidecar 패턴

따라서 pod의 구조는 보통 메인 기능을 하는 1개의 primary container와 메인 기능 보조나 추가 기능을 하는 여러 개의 sidecar container로 분리된다.

Pod 실습

Pod 만들기

다음과 같이 yaml을 만들고 apply를 해서 pod을 만들 수 있다.

// kubia.yaml
apiVersion: v1 
kind: Pod 
metadata:
 name: kubia
spec:
 containers:
 - name: kubia
 image: luksa/kubia:1.0
 ports:
 - containerPort: 8080

$ kubectl apply -f pod.kiada.yaml
pod "kiada" created

이렇게 만들어진 pod의 정보를 보자.

$ kubectl get pod kiada
NAME READY STATUS RESTARTS AGE
kiada 1/1 Running 0 32s

$ kubectl describe pod kiada
Name: kiada
Namespace: default
Priority: 0
Node: worker2/172.18.0.4
Start Time: Mon, 27 Jan 2020 12:53:28 +0100
...

Request 보내기

pod 자체의 고유 IP주소가 있지만 이것은 내부에서 다른 pod들이 접근할때 사용됨 -> 다른 방법 필요

$ kubectl get pod kiada -o wide
NAME     READY     STATUS     RESTARTS     AGE    IP             NODE     ...
kiada     1/1     Running    0             35m 10.244.2.4     worker2 ...

IP를 확인했으니 이제 port 번호만 pod definition에서 확인하면 주소가 확정된다. 알아낸 주소로 보내면 응답이 온다.

$ curl 10.244.2.4:8080
Kiada version 0.1. Request processed by "kiada". Client IP: ::ffff:10.244.2.1

로컬에서 확인할 경우, kubectl port-forward를 사용하여 통신하는 방법이 있다. 로컬로 연결되는 proxy를 사용하여 통신한다.

$ kubectl port-forward kiada 8080
... Forwarding from 127.0.0.1:8080 -> 8080
... Forwarding from [::1]:8080 -> 8080

$ curl localhost:8080
Kiada version 0.1. Request processed by "kiada". Client IP: ::ffff:127.0.0.1

이것을 그림으로 나타내면 다음과 같다.

Request log 확인

node.js application은 stdout으로 log를 보내기 때문에, 다음과 같이 확인할 수 있다.

$ kubectl logs kiada
Kiada - Kubernetes in Action Demo Application
---------------------------------------------
Kiada 0.1 starting...
Local hostname is kiada
Listening on port 8080
Received request for / from ::ffff:10.244.2.1 #A
Received request for / from ::ffff:10.244.2.5 #B
Received request for / from ::ffff:127.0.0.1 #C

또는 이렇게 하면 로그를 실시간으로 볼 수 있다.

$ kubectl logs kiada -f 

File copy

$ kubectl cp kiada:html/index.html /tmp/index.html

명령어 실행

$ kubectl exec kiada -- ps aux

Kubernetes API란?

Kubernetes cluster 안의 정보들을 CRUD하기 위한 http based RESTful API

REST API를 통해 CRUD할 수 있는 cluster의 구성정보들을 resource나 object라고 부른다. resource는 /apis/apps/v1/namespaces/myns/deployments/mydeploy 이런 느낌으로 카테고리 > 세부문서 > 카테고리 > 세부문서 로 파싱 가능하다.

object의 구성요소 4가지:

1. Metadata - object의 type을, type이 속한 그룹, 버전들을 나타낸다. 2. Object Metadata - object의 이름, 생성 날짜, 소유자 등을 나타낸다. 3. Spec - object가 되기를 바라는 상태(desired state)를 나타낸다. Pod의 경우 이는 Pod의 컨테이너, 저장공간 크기 등이다. 4. Status - object의 실제 상태(actual state)를 나타낸다. Pod의 경우 이는 Pod의 상태, 각 컨테이너의 상태, IP 주소, 실행 중인 노드 등과 같이 Pod에 대한 현재 상황을 나타내는 정보이다.

Kubernetes Control plane은 각각의 type에 맞는 type controller를 사용해 Spec의 내용을 읽어와 desired state가 되도록 수행하고, 결과를 Status에 저장하여 보내준다.

Kubernetes API 예제

Node 배치 확인

예를 들어서 kubectl get nodes 명령시 다음과 같은 결과가 나왔다고 해보자.

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kind-control-plane Ready master 1h v1.18.2
kind-worker Ready <none> 1h v1.18.2
kind-worker2 Ready <none> 1h v1.18.2 

그러면 Kubernetes API는 그림과 같이 구성된다. API 안의 node object들은 각각 실제 node(즉 실제 컴퓨터)와 대응된다.

kubectl get node

node object의 정보를 자세히 확인하려면 kubectl get node <node-name> -o yaml 명령을 입력한다. object의 4가지 구성요소가 있는것을 확인할 수 있다.

$ kubectl get node kind-control-plane -o yaml
apiVersion: v1
kind: Node
metadata:
 annotations: ...
 creationTimestamp: "2020-05-03T15:09:17Z" 
 labels: ...
 managedFields: ...
 name: kind-control-plane
 resourceVersion: "3220054"
 selfLink: /api/v1/nodes/kind-control-plane
 uid: 16dc1e0b-8d34-4cfb-8ade-3b0e91ec838b 
spec:
 podCIDR: 10.244.0.0/24
 podCIDRs:
 - 10.244.0.0/24
 taints:
 - effect: NoSchedule
 key: node-role.kubernetes.io/master 
status:
 addresses:
 - address: 172.18.0.2 
 type: InternalIP
 - address: kind-control-plane
 type: Hostname 
 allocatable: ...
 capacity:
 cpu: "8" 
 ephemeral-storage: 401520944Ki
 hugepages-1Gi: "0" 
 hugepages-2Mi: "0"
 memory: 32720824Ki 
 pods: "110" 
 conditions: 
 - lastHeartbeatTime: "2020-05-17T12:28:41Z"
 lastTransitionTime: "2020-05-03T15:09:17Z"
 message: kubelet has sufficient memory available 
 reason: KubeletHasSufficientMemory
 status: "False"
 type: MemoryPressure
 ...
 daemonEndpoints:
 kubeletEndpoint:
 Port: 10250 
 images:
 - names:
 - k8s.gcr.io/etcd:3.4.3-0
 sizeBytes: 289997247
 ...
 nodeInfo:
 architecture: amd64 
 bootID: 233a359f-5897-4860-863d-06546130e1ff 
 containerRuntimeVersion: containerd://1.3.3-14-g449e9269
 kernelVersion: 5.5.10-200.fc31.x86_64
 kubeProxyVersion: v1.18.2
 kubeletVersion: v1.18.2 
 machineID: 74b74e389bb246e99abdf731d145142d
 operatingSystem: linux
 osImage: Ubuntu 19.10
 systemUUID: 8749f818-8269-4a02-bdc2-84bf5fa21700

사실 너무 길어서 처음부터 무슨말인지 알아보기 힘들다..

conditions

node의 status 필드의 한 예시로 conditions라는 부분이 있다. conditions란 object가 현재 처한 상황들을 배열로 저장해놓은 것이다. 디버깅할 때 많이 쓰이므로, 각 구성요소만 짧게 알아보자. lastTransitionTime: conditions가 마지막으로 업데이트된 시점 lastHeartbeatTime: conditions 업데이트가 마지막으로 controller에게 전달된 시점 message, reason: 현재 상태 type: 어느 영역에서 해당 conditions가 나타나는지 status: conditions를 True, False, Unknown으로 알려줌

kubectl explain

필드들에 대한 자세한 설명은 kubectl explain <kind> 아니면 kubectl explain <kind>.<subkind> 이런식으로 입력하면 각 object들의 field에 대한 설명이 나온다.

$ kubectl explain nodes
KIND: Node
VERSION: v1
DESCRIPTION:
 Node is a worker node in Kubernetes. Each node will have a unique
 identifier in the cache (i.e. in etcd).
FIELDS:
 apiVersion <string>
 APIVersion defines the versioned schema of this representation of an
 object. Servers should convert recognized schemas to the latest...
 kind <string>
 Kind is a string value representing the REST resource this object
 represents. Servers may infer this from the endpoint the client...
 metadata <Object>
 Standard object's metadata. More info: ...
 spec <Object>
 Spec defines the behavior of a node...
 status <Object>
 Most recently observed status of the node. Populated by the system.
 Read-only. More info: ... 

kubectl describe

kubectl describe라는 명령도 입력해볼 수 있다. 이것은 아까 했던 kubectl get node <node-name> -o yaml를 조금 간략하게 정리해주고, 자원 할당량과 최근 이벤트들을 표시한다.

$ kubectl describe node kind-worker-2
Name: kind-worker2
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
 beta.kubernetes.io/os=linux
 kubernetes.io/arch=amd64
 kubernetes.io/hostname=kind-worker2
 kubernetes.io/os=linux
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /run/contain...
 node.alpha.kubernetes.io/ttl: 0 
  volumes.kubernetes.io/controller-managed-attach-deta...
CreationTimestamp: Sun, 03 May 2020 17:09:48 +0200
Taints: <none>
Unschedulable: false
Lease:
 HolderIdentity: kind-worker2
 AcquireTime: <unset>
 RenewTime: Sun, 17 May 2020 16:15:03 +0200
Conditions:
 Type Status ... Reason Message
 ---- ------ --- ------ -------
 MemoryPressure False ... KubeletHasSufficientMemory ...
 DiskPressure False ... KubeletHasNoDiskPressure ...
 PIDPressure False ... KubeletHasSufficientPID ...
 Ready True ... KubeletReady ...
Addresses:
 InternalIP: 172.18.0.4
 Hostname: kind-worker2
Capacity:
 cpu: 8
 ephemeral-storage: 401520944Ki
 hugepages-1Gi: 0
 hugepages-2Mi: 0
 memory: 32720824Ki
 pods: 110
Allocatable:
 ...
System Info:
 ...
PodCIDR: 10.244.1.0/24
PodCIDRs: 10.244.1.0/24
Non-terminated Pods: (2 in total)
 Namespace Name CPU Requests CPU Limits ... AGE
 --------- ---- ------------ ---------- ... ---
 kube-system kindnet-4xmjh 100m (1%) 100m (1%) ... 13d
 kube-system kube-proxy-dgkfm 0 (0%) 0 (0%) ... 13d
Allocated resources:
 (Total limits may be over 100 percent, i.e., overcommitted.)
 Resource Requests Limits
 -------- -------- ------
 cpu 100m (1%) 100m (1%)
 memory 50Mi (0%) 50Mi (0%)
 ephemeral-storage 0 (0%) 0 (0%)
 hugepages-1Gi 0 (0%) 0 (0%)
 hugepages-2Mi 0 (0%) 0 (0%)
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Starting 3m50s kubelet, kind-worker2 ...
 Normal NodeAllocatableEnforced 3m50s kubelet, kind-worker2 ...
 Normal NodeHasSufficientMemory 3m50s kubelet, kind-worker2 ...
 Normal NodeHasNoDiskPressure 3m50s kubelet, kind-worker2 ...
 Normal NodeHasSufficientPID 3m50s kubelet, kind-worker2 ...
 Normal Starting 3m49s kube-proxy, kind-worker2 ... 

event object

controller가 current state과 desired state를 맞춰가기 위해 작업한 목록들을 적어놓은 object이다. Normal 타입의 이벤트는 정상적으로 처리된 것, Warning 타입은 뭔가가 방해한 것이다. event object는 controll plane의 etcd에 저장되고, 생성되고 1시간 후에 지워진다.

event object들도 kubectl get 커맨드로 볼 수 있다. Type이 Warning인 것만 보려면, kubectl get ev --field-selector type=Warning 이렇게 검색하면 된다.

Kubernetes 사용법

(prerequisites) docker

Kubernetes cluster는 docker를 통해 실행시킬 수 있다.

docker에서 환경설정 -> Kubernetes -> Enable Kubernetes

docker의 container는 다음과 같은 구조를 갖는다.

Minikube

1. https://github.com/kubernetes/minikube 들어간다.
2. Readme의 Installation 들어가서 파일 다운받는다.
3. minikube start

C:\Windows\system32>minikube start
* minikube v1.32.0 on Microsoft Windows 10 Education 10.0.19045.4046 Build 19045.4046
* Automatically selected the docker driver. Other choices: hyperv, virtualbox, ssh
* Using Docker Desktop driver with root privileges
* Starting control plane node minikube in cluster minikube
* Pulling base image ...
* Downloading Kubernetes v1.28.3 preload ...
    > preloaded-images-k8s-v18-v1...:  403.35 MiB / 403.35 MiB  100.00% 27.43 M
    > gcr.io/k8s-minikube/kicbase...:  453.90 MiB / 453.90 MiB  100.00% 25.04 M
* Creating docker container (CPUs=2, Memory=4000MB) ...
* Preparing Kubernetes v1.28.3 on Docker 24.0.7 ...
  - Generating certificates and keys ...
  - Booting up control plane ...
  - Configuring RBAC rules ...
* Configuring bridge CNI (Container Networking Interface) ...
* Verifying Kubernetes components...
  - Using image gcr.io/k8s-minikube/storage-provisioner:v5
* Enabled addons: storage-provisioner, default-storageclass
* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

minikube의 구조는 다음과 같다.

Kind (Kubernetes in docker)

kind는 minikube와 달리 한 cluster에 여러 개의 node가 들어가 있다. VM 환경이 따로 지원되지 않아, 컨테이너는 host OS와 같은 환경에서 실행되고 따라서 컨테이너 내부에서 같은 컴파일 환경이나 프로그램 동작등을 지원할 수 있다.

다음은 kind의 작동 방식이다.

GKE (Google Kubernetes Engine)

Google에서 Kubernetes의 기능들을 google cloud로 지원해 주어 복잡한 초기 설정 없이 인터넷 환경에서 바로 이용하게 해주는 것이다. 구조는 다음과 같다.

직접 엔진 만들기

직접 Kubernetes 서비스의 구조를 만들어 볼 수도 있다. https://github.com/kelseyhightower/Kubernetes-the-hard-way

나중에 써먹을지도..?

Kubernetes cli

kubectl(kube controller)

kubectl은 Control plane에 요청할 수 있는 cli tool이다. 다음과 같은 구조로 유저가 kubectl를 통해 API Server에 전달하면, Control plane이 요청에 맞는 작업을 수행한다.

kubectl의 기본적인 명령어들은 다음과 같다.

• Kubernetes의 현재 cluster 상태 정보 확인

$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:53107
CoreDNS is running at https://127.0.0.1:53107/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

• 현재 모든 node들 list up 하기

$ kubectl get nodes
NAME                 STATUS   ROLES           AGE    VERSION
kind-control-plane   Ready    control-plane   102m   v1.29.2

• 선택한 node 정보 자세히 알아보기

$ kubectl describe node kind-control-plane
Name:               kind-control-plane
Roles:              control-plane
...

kube dashboard

GUI로 현재 상태를 확인할 수 있는 대시보드 또한 존재한다.

Kubernetes 핵심 개념

pod

pod란 container들을 묶어서 같은 namespace를 공유하고 한번에 실행할 수 있게 하느 단위로, 같은 pod은 IP(network namespace)와 system hostname(UTS namespace)같은걸 공유할 수 있고 서로 더 쉽게 통신할 수 있다.

즉 pod이란 하나의 application를 실행하는 논리적인 컴퓨터라고 할 수 있다. application에서는 한개 또는 여러개의 container를 필요로 할 수도 있다.

deployment

deployment는 pod을 정해진 replica 수만큼 생성하고 id를 부여하는 object이다. pod이 갑자기 삭제되거나 pod이 존재하는 노드의 이상 등으로 문제가 생길 때, deployment는 replica의 수를 일정하게 만들어주기 위해 추가로 pod을 만들어준다.

service

service는 실행중인 pod들이 외부와 통신할 수 있도록 연결해주는 object이다. 외부에서 요청이 들어오면 service는 traffic에 따라 pod들에게 적절히 load-balancing해주고, pod이 삭제되고 재생성될 경우, 변경된 IP주소등 pod의 정보를 갱신한다.

이것들의 논리적 구조는 다음과 같다.

Kubernetes 실습

kubernetes cluster에 application을 넣어본다. 미리 요약하자면 kubectl create deployment 명령어를 통해 pod을 만들고, kubectl expose deployment를 통해 외부로 노출시키면 된다.

1. luksa/kubia:1.0라는 container를 사용하여 kubia라는 deployment를 만든다.

$ kubectl create deployment kubia --image=luksa/kubia:1.0
deployment.apps/kubia created 

deployment object용 container들의 상태를 확인해보면 방금 만든게 나올 것이다.

$ kubectl get deployments
NAME     READY     UP-TO-DATE     AVAILABLE     AGE
kubia     0/1     1             0             6s 

UP-TO_DATE가 1이므로 이 application은 1개의 instance를 갖는다. 또한 AVAILABLE이 0이므로 application이 아직 사용할수 없음을 나타낸다.

2. deployment로 만들어진 pod의 정보를 확인한다. 생성한 container가 들어있는 pod을 확인할 수 있다.

$ kubectl get pods
NAME                     READY     STATUS     RESTARTS    AGE
kubia-587b7cd6b7-85zbh     0/1     Pending    0             1m 

pod이 Ready 상태인데, 이것은 pod이 할당된 worker node가 container image를 다운받고 있는 중이기 때문이다. 모두 다운받으면 Running state로 넘어간다.

pod의 로그등 자세한 정보를 확인하려면 다음과 같이 한다.

$ kubectl describe pod
Name:             kubia-587b7cd6b7-85zbh
Namespace:        default

...

Events:
  Type    Reason          Age   From     Message
  ----    ------          ----  ----     -------
  Normal  SandboxChanged  21m   kubelet  Pod sandbox changed, it will be killed and re-created.
  Normal  Pulled          21m   kubelet  Container image "luksa/kubia:1.0" already present on machine
  Normal  Created         21m   kubelet  Created container kubia
  Normal  Started         21m   kubelet  Started container kubia

이 과정을 그림으로 나타내면 다음과 같다.

3. service object를 만든다. load balancer service라는 service object를 만들어, 이를 통해 외부와 통신할 수 있다.

$ kubectl expose deployment kubia --type=LoadBalancer --port 8080
service/kubia exposed

생성된 service 객체를 확인하면 다음과 같다.

$ kubectl get svc
NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP      10.96.0.1     <none>        443/TCP          18h
kubia        LoadBalancer   10.96.245.7   <pending>     8080:30953/TCP   3m7s

load balancer service까지 만들게 되면, kubernetes는 외부의 cloud 서비스에게 load-balancer를 제공하도록 요청한다. 그러면 cloud provider가 load-balancer를 만들고 사용자의 traffic을 잘 쪼개어 worker node들에 보내준다.

4. load-balancer가 만들어지면 EXTERNAL-IP가 생성되고 이것을 통해 요청을 보낼 수 있다.

+ minikube를 사용하는 경우 load balaner를 제공해주지 않는데, 이 경우 minikube service kubia --url 명령으로 외부주소를 찾아내면 된다.

5. 더 많은 traffic에 대비해 horizontal scaling out을 진행한다.

$ kubectl scale deployment kubia --replicas=3
deployment.apps/kubia scaled 

이렇게 하면 다음과 같이 pod가 확장된다.

$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
kubia 3/3 3 3 18m 

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kubia-9d785b578-58vhc 1/1 Running 0 17s
kubia-9d785b578-jmnj8 1/1 Running 0 17s
kubia-9d785b578-p449x 1/1 Running 0 18m 

각 pod가 어떤 node에 담겼는지 확인하려면 다음과 같이 한다.

$ kubectl get pods -o wide
NAME ... IP NODE
kubia-9d785b578-58vhc ... 10.244.1.5 worker1 #A
kubia-9d785b578-jmnj8 ... 10.244.2.4 worker2 #B
kubia-9d785b578-p449x ... 10.244.2.3 worker2 #B 

pod을 여러개 만들어 node들에 뿌릴 경우, 요청들에 대한 흐름도는 적절한 load-balancing을 통해 pod들로 뿌려진다.

Container와 Virtual machine 비교

Container는 VM과 다르게 하나의 OS 위에서 process 단위로만 나눈다 -> VM보다 훨씬 가벼움 하나의 Container위에서는 무조건 하나의 application만 동작!

system call등을 단일 kernel 하나로만 처리함. 하지만 container들끼리는 다른 container를 무시하고 자신만 kernel과 통신하는 것으로 취급됨. 하지만 논리적으로 완벽한 분리는 아니므로 VM보다 안정적으로 독립성 보장은 X.

Docker 알아보기

application을 패키징하여 distributing, running하는 플랫폼으로 도커를 사용하면 application을 필요한 환경(DLL, OS의 부분 등)과 하나로 묶어 다른 OS를 가진 어떤 컴퓨터 위에서든 실행 가능

Docker의 핵심 개념 3가지 Image - application과 필요한 환경을 하나로 묶어 zip해 놓은 패키지 단위 Registry - Image의 저장소이고, 다른사람과 공유 가능. git같은 개념인듯 Container - Image를 instance화 하여 제한된 리소스 하에서 실행하는 공간

Image layer application을 실행하기 위한 요구사항들을 layer로 쌓아서 관리함 Q. 그러면 container 공통으로 쓰이는 file들에 대해서는 자원의 변경사항을 공유하는 것 아닌가? A. container 각각의 read-write layer에서 file을 수정하므로 read-only layer에 있는 원본에는 변화 X

Docker의 한계

Docker에서는 자체적인 kernel를 가지고 있지 않으므로 application이 요구하는 kernel 버전이나 kernel module이 없으면 실행 불가능 -> hardware architecture이 다르면(ex. x86과 ARM) 실행 불가능

Docker자체는 process를 격리하지 않고, 실제 container 격리는 linux kernel 수준에서 이루어진다.

Docker 실습

컨테이너 다운받기

busybox - echo, ls등 linux 명령어들 모아놓은 단일파일

$ docker run busybox echo "Hello World"

실행하면 다음과 같이 나온다.

Unable to find image 'busybox:latest' locally latest: Pulling from library/busybox 7c9d20b9b6cd: Pull complete Digest: sha256:fe301db49df08c384001ed752dff6d52b4… Status: Downloaded newer image for busybox:latest Hello World

이것의 작동 원리는 다음과 같다.

1. Docker CLI에서 Docker daemon에 명령 전달
2. Docker daemon이 로컬에서 해당 image 있는지 확인
3. 없으므로 registry에서 image 가져옴
4. Docker에서 container 만든 후 echo "Hello World" 커맨드 실행

파일 직접 패키징하여 업로드하기

1. 파일 하나 만든다.

   // app.js
   

const http = require('http'); const os = require('os'); const listenPort = 8080; 36 ©Manning Publications Co. To comment go to liveBook console.log("Kubia server starting..."); console.log("Local hostname is " + os.hostname()); console.log("Listening on port " + listenPort); var handler = function(request, response) { let clientIP = request.connection.remoteAddress; console.log("Received request for "+request.url+" from "+clientIP); response.writeHead(200); response.write("Hey there, this is "+os.hostname()+". "); response.write("Your IP is "+clientIP+". "); response.end("\n"); }; var server = http.createServer(handler); server.listen(listenPort);

2. Dockerfile이라는 것을 만들어야 한다.

// Dockerfile

FROM node:12 ADD app.js /app.js ENTRYPOINT ["node", "app.js"]

3. Docker cli로 실행시켜준다.
> $ docker build -t kubia:latest .

4. 완성된 image는 docker images 명령어로 확인해보면 다음과 같이 나온다.
> kubia        latest    ca0deb942e03   About a minute ago   918MB

빌드의 원리는 다음과 같다.


![](https://velog.velcdn.com/images/hyunsu_prog/post/338e83ae-33ea-420a-84c2-812dddcd4bef/image.png)

1. Docker cli가 명령어를 가지고 파일들을 Linux에 있는 Docker daemon으로 보내준다.
2. Docker Daemon이 node:12 이미지를 가져온다.
3. Dockerfile의 명령어 한줄씩 layer를 추가해준다.


이미지를 실행하려면 다음 명령어를 입력한다.
> $ docker run --name kubia-container -p 1234:8080 -d kubia

kubia 이미지로부터 kubia-container라는 이름의 컨테이너를 만들고 local 컴퓨터의 1234포트를 컨테이너의 8080과 연결하여 실행한다.
![](https://velog.velcdn.com/images/hyunsu_prog/post/e10afce3-f296-49f0-92e4-67e7e342cdc2/image.png)

### 이미지 배포하기

1. 이미지에 tag(이미지의 다른 이름 + 버전정보)를 붙여준다.
> $ docker tag kubia luksa/kubia:1.0 

2. docker에 로그인한 후 업로드한다.
> $ docker login -u yourid -p yourpassword docker.io
$ docker push yourid/kubia:1.0

3. 다른 컴퓨터에서 이미지를 받아 쓰려면 다음을 입력한다.
> $ docker run -p 1234:8080 -d yourid/kubia:1.0 

### 컨테이너 삭제하기

1. 컨테이너를 종료시킨다.
> $ docker stop kubia-container

2. 컨테이너와 이미지를 삭제한다.
> $ docker rmi kubia:latest 

 
## 컨테이너가 Isolation을 유지하는 방법

### Linux Namespace
OS의 자원들을 분할해주는 단위, process는 각각의 자원별로(파일, 네트워크, 시스템 이름 등) 자기만의 namespace를 설정하여 그 안의 자원만 참조한다.
**but)** 가끔씩 프로세스가 같은 namespace를 공유하게 하고 싶을 수도 있다.

#### Ex1) Network namespace
어떤 network interface들을 사용할 것인지 정의해 놓는 namespace. 하나의 network interface는 하나의 network namespace에만 소속될 수 있다.
![](https://velog.velcdn.com/images/hyunsu_prog/post/968d933c-0569-4884-a613-8bca72145f56/image.png)

#### Ex2) UTS namespace
프로세스가 system host name과 domain name을 뭐라고 보는지 정의하는 namespace.
두 프로세스의 UTS namespace가 다르면 서로 다른 컴퓨터 환경에서 돌아가는 것이라고 여기게 된다.

### Linux Control Groups
Linux namespace에서는 같은 OS 자원을 얼마만큼 사용할지는 정의 X
Linux Control Groups를 통해 사용하는 cpu, memory 등의 할당량 설정 가능.

### Previlege
프로세스가 어떤 system call 실행 등의 시스템 자원을 건드릴 수 있는지 권한을 설정함으로써 커널 내부의 데이터들이 이상하게 바뀌는 것 방지

Kubernetes란?

기반이 되는 hardware들 위에 abstraction layer를 제공하여 이용자들이 low-level에 신경쓰지 않고 프로그램을 쉽게 deploy하도록 도와주는 프레임워크
아래의 사진에서 나와있듯이 개발자는 application을 networt나 computer에 대한 고려 없이 Kubernetes level 위에서 실행시킬 수 있다.

Kubernetes는 왜 필요한가?

1. Microservices

기존의 Monolithic application -> 하나의 쪼갤 수 없는 단위, horizontally scaling(여러 대의 컴퓨터로 실행하는 것) 불가능 Microservices로 옮겨가며 application을 분할할 필요성 증가 but) Microservices의 경우 여러 OS의 여러 버전의 library를 관리하기 까다로움 -> 분산 컴퓨팅 프레임워크

2. DevOps Paradigm

DevOps란 ? 소프트웨어를 만드는 development team과 완성된 제품을 가지고 deploy하는 management team으로 나뉘는 구조 Kubernetes를 사용하면 더 실시간으로 소프트웨어를 개선시킬 수 있다.

3. Cloud화 진행

기존의 local에 있었던 코드는 옮기는데 비용 많이 듦 -> 코드를 cloud에 배포 Kubernetes API를 통해 AWS, Google Cloud등 여러 Cloud에 쉽게 접근 가능

Kubernetes 이해하기

Kubernetes와 OS의 비교) OS가 Scheduler를 통해 CPU를 할당해 주고 interface를 지원해 주는 것처럼 Kubernetes는 Server들을 Scheduling해 주고 interface를 제공해 사용자가 다음과 같은 infrastructure를 몰라도 되도록 해준다.

Infrastructure (Kubernetes의 주 기능)

service discovery - 어떤 application이 다른 application의 서비스를 이용하게 해주는 것 horizontal scaling - traffic이 증가했을 때 application의 개수를 복제하여 부담을 분할시키는 것 load-balancing - 복제된 application의 load(부담)이 치우치지 않게 해주는 것 self-healing - application이 죽었을 때 자동으로 restart해주고 healty node로 옮겨주는 것 leader election - 어떤 instance를 active시킬지, active된 instance가 죽었을 때 어떤 instance로 옮겨갈 것인지 설정

Kubernetes상에서 machine은 크게 Master node, Worker node 2가지로 나뉘어진다.   Master node - system과 cluster들을 제어, 보통 최소 3개는 필요함. Worker node - application을 실행하는 machine으로 application의 개수를 맞춰간다.

Kubernetes 프레임워크가 만들어지면 Kubernetes 내부에서 자동으로 application을 적절한 node들로 배치하고 이동시켜 주므로, 유저는 Control Plane에서 제공하는 Kubernetes API만으로 Workload Plane의 application을 제어할 수 있게 된다.

Cluster

Cluster란, Control plane과 Workload Plane이 모여서 만들어진 큰 단위이다.

Control plane

API Server - REST API형식으로 요청을 받아서 object를 생성한다. etcd - API를 통해 만든 object들을 persistent datastore에 저장한다. why? API Server 자체는 stateless하기 때문 Scheduler - 어떤 application을 어떤 worker node에서 실행할 것인지 결정한다. Controllers - 생성된 object을 관리한다.

Worker node

Kubelet - API Server와 통신하고 application과 node의 상태를 감시하고 관리한다. Container Runtime - Kubelet에 지시를 받아 application을 실행한다. 일반적으로 Docker같은 것. Kube Proxy - application들 사이의 network traffic을 load-balance 해준다.

Add-on

DNS 서버, 네트워크 플러그인, 로그 기록들을 추가한다. 보통 Worker node에서 실행된다.

Kubernetes 작동 방식

Kubernetes에서는 object를 기본 단위로 한다. 하나의 소프트웨어에는 deployment하는 object, instance running 하는 object, 서비스를 나타내는 object등 다양한 object들이 있다. 전체 object들의 description은 yaml이나 json으로 관리된다. 이것들은 보통 kubetcl(K8s의 cli)로 object단위로 쪼개지고, PUT이나 POST 요청으로 API서버에 전해진다.

Kubernetess 내부 과정

1. object들의 정보를 담은 application menifest를 API서버에 보낸다. API서버는 이것을 etcd에 저장한다.
2. 각 type에 object에 대응하는 Controller가 새로운 object들을 실제로 생성한다.
3. Scheduler가 object들을 node에 할당한다.
4. object가 할당된 node의 Kubelet이 Container Runtime에게 instance(할당된 object)를 실행시킨다.
5. Kube proxy가 instance가 사용 준비됨을 알리고 load-balancing 한다.
6. Kubelet과 Controller가 시스템을 정상적으로 돌아가도록 관리한다. 또한 주기적으로 상태를 알려준다.

Kubernetes 사용 상황

On-Premises - 로컬로 시스템 작동, HPA하기 힘들다. Cloud - Cloud 서버로 시스템 작동, HPA 유연하다. Hybrid - 평소에는 로컬로 저장, peak일 때 instance추가로 받는다