지난 밋업에서 스터디 그룹을 만들었는데 오늘은 그 첫번째 시간으로 101 에 대한 스터디를 하였습니다.

발표자

1회 발표자 - 최진영, 이재규

1회 스터디 주제 목록

• Concepts >> Workloads (항목 전부)

  • https://kubernetes.io/docs/concepts/workloads/

• Tasks >> Configure Pods and Containers (항목 전부)

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

• Tutorials >> Hello Minikube

  • https://kubernetes.io/docs/tutorials/hello-minikube/

• Tutorials >> Learn Kubernetes Basic (중에서 우선 아래 2개만)

  • https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/

  • https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-app/

101 스터디 발표 - 최진영

101 에서는 최진영님이 첫 발표를 해주셨습니다.

Kubernetes 아키텍처 구조 및 Component들 설명

etcd

• 모든 상태와 데이터를 저장

• 분산 시스템으로 구성하여 안전성을 높임 (고가용성)

• 가볍고 빠르면서 정확하게 설계 (일관성)

• Key(directory)-Value 형태로 데이터 저장

API-server

• 상태를 바꾸거나 조회

• etcd와 유일하게 통신하는 모듈

• REST API 형태로 제공

• 권한을 체크하여 적절한 권한이 없을 경우 요청을 차단, 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신

• 수평으로 확장되도록 디자인(요청이 많기 때문에)

Scheduler

• 새로 생성된 Pod을 감지하고 실행할 노드를 선택

• 노드의 현재 상태와 Pod의 요구사항을 체크

Controller

• 끊임 없이 상태를 체크하고 원하는 상태를 유지

Object 설명

실습주소: https://bit.ly/3TN9fUM (pod, replicaset, deployment, namespace, service)

• Container: 컨테이너는 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지입니다.

• Pod: 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.(하나이상의 컨테이너 그룹)

• ReplicaSet: 레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.

  이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.

• Deployment: 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다. 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.

• StatefulSet: 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다.

  예를 들면, 워크로드가 데이터를 지속적으로 기록하는 경우, 사용자는 Pod 와 PersistentVolume을 연계하는 StatefulSet 을 실행할 수 있다.

  전체적인 회복력 향상을 위해서, StatefulSet 의 Pods 에서 동작 중인 코드는 동일한 StatefulSet 의 다른 Pods 로 데이터를 복제할 수 있다.

• DaemonSet: 노드-로컬 기능(node-local facilities)을 제공하는 Pods 를 정의한다. 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.

  예를 들면, 네트워킹 지원 도구 또는 add-on 등이 있다. DaemonSet 의 명세에 맞는 노드를 클러스터에 추가할 때마다, 컨트롤 플레인은 해당 신규 노드에 DaemonSet 을 위한 Pod 를 스케줄한다.

• Job: 단 한번만 실행 완료 후 중단되는 작업을 정의

• CronJob: 스케줄에 따라 반복되고 실행 완료 후 중단되는 작업을 정의

• Static Pod: 스태틱 파드는API 서버없이 특정 노드에 있는 kubelet 데몬에 의해 직접 관리된다.

  컨트롤 플레인에 의해 관리되는 파드(예를 들어디플로이먼트(Deployment))와는 달리, kubelet 이 각각의 스태틱 파드를 감시한다. (만약 실패할 경우 다시 구동한다.)

• 노드: 쿠버네티스는 컨테이너를 파드내에 배치하고 노드 에서 실행함으로 워크로드를 구동한다. 노드는 클러스터에 따라 가상(EC2) 또는 물리적 머신일 수 있다.

  • 컨트롤 플레인(마스터 노드): 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다.

  • 데이타 플레인(워커 노드): 워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다.

• 컨피그맵(ConfigMap): 컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장

• 시크릿(Secret): 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트

• 서비스: 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법

• 네임스페이스: 네임스페이스 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다.

Pod스케줄링 방법(원하는 노드에 원하는 pod을 배포 하기위함)

• Predicates: 볼륨이나, cpu, memory 같은 리소스들을 확인하고 스케줄러가 적당한 노드를 골라서 배포(cpu, memory등 Quota를 정할수 있음)

• Taint-toleration: 특정 노드에 파드를 배포할수 없도록 하는 방법. Taint(때, 더러움) 를 묻혀 기록해 놓음, Taint가 있는 노드에 파드에 배포할려면 Toleration을 정의해서 배포가능하게 할수 있음.

• nodeSelector: label을 통해 특정 노드에 배포

• nodeName: 노드 이름으로 특정 노드에 배포

• affinity: 특정 노드에 파드를 배포되게 하는 방법 또는 특정 파드들을 같은 노드에 배포 되게 하는 방법

  • Node Affinity: 특정 노드에만 실행

  • Node Anti-Affinity: 특정 노드 이외에서 실행

  • Inter-Pod Affinity: 특정 Pod가 있는 도메인(노드, 영역)에서 실행

  • Inter-Pod Anti-Affinity: 특정 Pod가 없는 도메인(노드, 영역)에서 실행

Resource 제한

• Resource Quota: 네임스페이스전체 오브젝트에 대한 사용량을 관리한다.

• Limit Ranges: 네임스페이스안에서 각 오브젝트(pod, pvc, container)에 대한 사용량을 관리한다.

• Requests&Limit: Pod안의 Container에 대한 사용량을 관리한다.

  • Assign Memory Resources to Containers and Pods

    • Request: 필수 사용량(파드의 메모리 request은 파드 내 모든 컨테이너의 메모리 request의 합)

    • Limit: 최대 사용량(파드의 메모리 limit은 파드 내 모든 컨테이너의 메모리 limit의 합)

    • 파드의 메모리 request을 적게 유지하여 파드가 높은 확률로 스케줄링 될 수 있도록 한다. 메모리를 Limit 보다 많이 사용하면 OOM Killer의 종료 대상 후보가 됨.

    • 컨테이너에 메모리 limit을 지정하지 않으면 다음 중 하나가 적용된다.

      • 컨테이너가 사용할 수 있는 메모리 limit은 없다. 컨테이너가 실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다.

        또한 메모리 부족으로 인한 종료 시 메모리 limit이 없는 컨테이너가 종료될 가능성이 크다.

      • 기본 메모리 limit을 갖는 네임스페이스 내에서 실행중인 컨테이너는 자동으로 기본 메모리 limit이 할당된다.

        클러스터 관리자들은 LimitRange를 사용해 메모리 limit의 기본 값을 지정 가능하다.

  • Assign CPU Resources to Containers and Pods

    • 500 milliCPU and a CPU limit of 1 CPU(1 vCPU),.

    • For example 100m CPU, 100 milliCPU, and 0.1 CPU are all the same.

    • Precision finer than 1m is not allowed.

      • CPU, Memory의 request 값을 지정하지 않으면 자동으로 limit으로 할당 된다.

  • Configure Quality of Service for Pods: 노드에서 리소스가 부적해 지면서 Resource pressure를 받으면 BestEffort → Burstable → Guaranteed 순으로 삭제 된다.

    • Guaranteed : request와 limit 값이 일치

    • Burstable: request나 limit 값이 일치 않지 않거나, 둘중 하나 만 있을때.

    • BestEffort: request나 limit 값을 지정하지 않았을때.

Assign Extended Resources to a Container

어떻게 왜 사용 하는지 모르겠음.

Volume

• Persistent Volume: 외부스토리지를 사용하여 파드가 삭제 되도 데이터가 삭제 되지 않는다

  • HostPath: Pod끼리 공유하기 위한 Node에 만들어지는 Storage.(공식문서에는 왠만하면 사용하지 말라고함)

  • 정적 프로비저닝: PersistentVolume

  • 동적 프로비저닝: StorageClass

  • PersistentVolume, StorageCalss 만들고 PersistenVolumeClaim으로 요청

• Ephemeral: 일부 애플리케이션은 추가적인 저장소를 필요로 하면서도 재시작 시 데이터의 영구적 보존 여부는 신경쓰지 않을 수도 있다. 예를 들어, 캐싱

  • EmptyDir: Pod내에서 Container끼리 공유 가능한 Storage. Pod이 지워지면 삭제

  • downwardAPI: 쿠버네티스에는 실행 중인 컨테이너에 파드 필드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다.

    환경 변수와 볼륨 파일이다. 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 downward API 라고 한다.

  • Secret

  • ConfigMap

  • generic Ephemeral Volume: 일반 임시 볼륨은 프로비저닝 후 일반적으로 비어 있는 스크래치 데이터에 대해 파드 별 디렉터리를 제공한다는 점에서 emptyDir 볼륨과 유사하다.

    하지만 다음과 같은 추가 기능도 제공한다.

    • 스토리지는 로컬이거나 네트워크 연결형(network-attached)일 수 있다.

    • 볼륨의 크기를 고정할 수 있으며 파드는 이 크기를 초과할 수 없다.

    • 드라이버와 파라미터에 따라 볼륨이 초기 데이터를 가질 수도 있다.

    • 볼륨에 대한 일반적인 작업은 드라이버가 지원하는 범위 내에서 지원된다. 이와 같은 작업은 다음을 포함한다. 스냅샷, 복제, 크기 조정, 및 스토리지 용량 추적.

  • Projected Volume: 프로젝티드 볼륨은 여러 기존 볼륨 소스(sources)를 동일한 디렉토리에 매핑한다.

    현재, 아래와 같은 볼륨 유형 소스를 프로젝트(project)할 수 있다. 모든 소스는 파드와 같은 네임스페이스에 있어야 한다.

    • 시크릿(secret)

    • downwardAPI

    • 컨피그맵(configMap)

    • 서비스어카운트토큰(serviceAccountToken)

  • VolumeSnapShot: PersistentVolume 용

  • VolumeSnapShotClass: StorageClass 용

Security

• 인증(Authentication)

  • User Account: 없음(on-premise kubernetes는 인증 어떻게 하세요?)

  • Service Account

    • When Pods contact the API server, Pods authenticate as a particular ServiceAccount (for example, default). There is always at least one ServiceAccount in each namespace.

      • serviceAccount: default(legacy)

      • serviceAccountName: default(new)

    • OIDC

• 권한 부여(Authorizations)

  • RBAC: Role, RoleBinding, ClusterRole, ClusterRoleBinding

Configure Liveness, Readiness and Startup Probes

• liveness Probes: The kubelet uses liveness probes to know when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs.

• Readiness Probes: The kubelet uses readiness probes to know when a container is ready to start accepting traffic. A Pod is considered ready when all of its containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.

• Startup Probes: kubelet은 컨테이너 애플리케이션이 언제 시작되었는지 알기 위해 시작 프로브를 사용한다. 이러한 프로브가 구성된 경우, 성공할 때까지 활성 및 준비 상태 확인을 비활성화하여 해당 프로브가 애플리케이션 시작을 방해하지 않도록 한다. 이를 통해 느리게 시작하는 컨테이너에 대한 상태 확인을 채택하여 컨테이너가 실행되기 전에 kubelet에 의해 종료되는 것을 방지할 수 있습니다

• Startup Probes와 Readiness Probes는 Pod이 시작되거나 애플리케이션이 준비되는 시점에서 다른 목적으로 사용됩니다. Startup Probes는 Pod이 시작될 때 애플리케이션이 제대로 작동하는지 확인하며, Readiness Probes는 Pod이 실행 중일 때 애플리케이션이 준비 상태인지 확인합니다. 이러한 프로브를 사용하여 Kubernetes 클러스터에서 안정적인 운영을 보장할 수 있습니다.

Configure Pod Initialization

• you create a Pod that has one application Container and one Init Container. The init container runs to completion before the application container starts.

Ephemeral Container

• 이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 기존 파드

  에서 임시적으로 실행된다. 임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다

• 파드 는 쿠버네티스 애플리케이션의 기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다. 대신, 사용자는 보통 디플로이먼트 를 사용해서 제어하는 방식으로 파드를 삭제하고 교체한다.

• 그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는 기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 실행할 수 있다.

• 임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 애플리케이션을 만드는데 적합하지 않다.

Attach Handlers to Container Lifecycle Events

• This page shows how to attach handlers to Container lifecycle events. Kubernetes supports the postStart and preStop events. Kubernetes sends the postStart event immediately after a Container is started, and it sends the preStop event immediately before the Container is terminated. A Container may specify one handler per event.

Disruption

• involuntary disruptions

  • a hardware failure of the physical machine backing the node

  • cluster administrator deletes VM (instance) by mistake

  • cloud provider or hypervisor failure makes VM disappear

  • a kernel panic

  • the node disappears from the cluster due to cluster network partition

  • eviction of a pod due to the node being out-of-resources.

• voluntary disruptions

  • deleting the deployment or other controller that manages the pod

  • updating a deployment's pod template causing a restart

  • directly deleting a pod (e.g. by accident)

  • Draining a node for repair or upgrade.

  • Draining a node from a cluster to scale the cluster down (learn about Cluster Autoscaling ).

  • Removing a pod from a node to permit something else to fit on that node.

• Dealing with disruptions: Here are some ways to mitigate involuntary disruptions

  • Ensure your pod requests the resources it needs.

  • Replicate your application if you need higher availability. (Learn about running replicated stateless and stateful applications.)

  • For even higher availability when running replicated applications, spread applications across racks (using anti-affinity) or across zones (if using a multi-zone cluster.)

  • Pod disruption budgets

Kubenetes Command

kubectl 명령어 k로 사용하기

alias k=kubectl

node 리스트 보기

kubectl get node

1. POD 만들어서 관리하기

Pod를 명령어로 만들기

#kubectl 명령어 [pod이름] —-image=[이미지이름]
kubectl run nginx-test --image=nginx

Pod의 리스트를 보기

kubectl get pods

Pod를 선언형(yaml)로 만들때 nginx-test2.yaml로 저장

vi nginx-test2.yaml 입력후

:set paste 입력후(이건 안하셔도 됩니다.)

i 누르면 입력 모드가 됩니다. 아래 내용을 그대로 복사하여 붙여넣으시고

ESC 누르시면 명령모드가 됩니다.

: 을 누르시면 명령을 입력하실수 있는데,

:wq 를 누르시고 엔터를 누르시면 저장 하고 나옵니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test2
  labels:
    app: nginx-test2
spec:
  containers:
  - image: nginx
    name: nginx-test2

위에 저장한 nginx-test2.yaml 로 Pod 만들기

kubectl apply -f nginx-test2.yaml

Pod의 리스트를 볼때 레이블까지 다 보는 명령어

kubectl get pod --show-labels

Pod의 리스트를 보기(어느 노드에 Pod이 배포 되었는지 확인 가능)

kubectl get pod -o wide

pod의 정보 자세히 보기

#kubectl describe pod [pod이름]
kubectl describe pod nginx-test

pod을 지우는 명령어

#kubectl delete pod [pod이름]
kubectl delete pod nginx-test

2. Replicaset 만들어 보기

yaml로 replicaset 만들기 (replicaset.yaml 로 저장)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-replicaset
  template:
    metadata:
      labels:
        app: nginx-replicaset
    spec:
      containers:
        - name: nginx-container
          image: nginx

아래 명령어 실행하여 replicaset 배포하기

kubectl apply -f replicaset.yaml

replicaset, pod 배포 되었는지 확인하기

kubectl get replicaset,pod

아래 명령어로 Pod 지우고 위에 명령어로 replicaset이 Pod를 잘 살려 주는지 확인하기

kubectl delete pod [pod이름]

3. Deployment 만들어보기

Yaml 로 Deployment 만들기 (deployment.yaml 로 저장)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      containers:
      - image: nginx
        name: nginx-container

아래 명령어 실행하여 deployment 배포하기

kubectl apply -f deployment.yaml

replicaset, pod, deployment 배포 되었는지 확인하기

kubectl get replicaset,pod,deployment

Pod 지워서 deployment가 Pod를 잘 살려 주는지 확인하기위해 파드를 삭제 해보고 다시 살아 나는지 확인

(중요: replicaset으로 만들어진 pod 이름을 넣을것)

kubectl delete pod [pod이름]

replicaset 변경 내용 모니터링 하는 명령어

(별도의 창을 하나 더 띄워서 이부분을 실행 해 놓고 4번 할것)

kubectl get replicaset -w

4. 새 Deployment 배포 하기

deployment.yaml 파일에서 image=nginx를 image=redis 로 변경한다. 그리고 다시 배포 한다.

아래 명령어 실행하여 deployment 다시 배포하기

kubectl apply -f deployment.yaml

5. 네임스페이스 관리하기

네임스페이스 리스트보기

kubectl get namespace

네임스페이스 만들기

#kubectl create namespace [namespace이름]
kubectl create namespace kube-test

특정 네임스페이스에 Pod 만들기

#kubectl run [만들pod이름] --image=nginx -n [특정네임스페이스이름]
kubectl run nginx --image=nginx -n kube-test

특정 네임스페이스의 Pod을 보기

#kubectl get pod -n [namepsace이름]
kubectl get pod -n kube-test

네임스페이스 지우기 (안에 pod도 지워짐)

#kubectl delete namespace [namespace이름]
kubectl delete namespace kube-test

6. 게임 배포하기

2048-game.yaml 파일로 저장하세요.

apiVersion: v1
kind: Namespace
metadata:
  name: "2048-game"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: "2048-deployment"
  namespace: "2048-game"
spec:
  selector:
    matchLabels:
      app: "2048"
  replicas: 5
  template:
    metadata:
      labels:
        app: "2048"
    spec:
      containers:
      - image: public.ecr.aws/kishorj/docker-2048:latest
        imagePullPolicy: Always
        name: "2048"
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: "service-2048"
  namespace: "2048-game"
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: "2048"

배포후 아래명령을 날리고 External-IP라는 부분의 주소를 브라우저에 붙이시면 됩니다.

kubectl apply -f 2048-game.yaml
kubectl get all -n 2048-game

네임 스페이스 지우기

kubectl delete ns 2048-game

101 스터디 발표 - 이재규

같은 내용으로 두번째 발표는 이재규님이 하셨습니다.

세부 내용은 아래 링크를 확인하시면 됩니다.

노션으로 정리했습니다.

Workloads

• Pods

  • Pod Lifecycle

  • Init Containers

  • Disruptions

  • Ephemeral Containers

  • Pod Quality of Service Classes (QoS)

  • User Namespaces

  • Downward API

• Workload Resources

  • Deployments

  • ReplicaSet

  • StatefulSets

  • DaemonSet

  • Jobs

  • Automatic Cleanup for Finished Jobs

  • CronJob

  • ReplicationController