kubernetes (1)

notion : https://wonderful-morocco-85b.notion.site/kubernetes-a21d8fd87b874a6f8ff527b2b6bdb950?pvs=4

kubernetes 회고록 | Notion

 

 

1일차 이론

 

Kubernetes(K8s)

 

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성 있고, 확장 가능한 오픈소스 플랫폼

k8s의 기능

• 서비스 디스커버리와 로드 밸런싱
• 스토리지 오케스트레이션
• 자동화된 롤아웃과 롤백
• 자동화된 빈 패킹
• 자동화된 복구
• 시크릿과 구성관리
• 이 밖에도 여러가지 기능!

k8s cluster

클러스터 안에 마스터노드와 워커노드들이 구성

 

마스터노드와 워커노드들이 Kube API Server를 통해 약속된 스케줄러를 실행시킴(?)

 

Pod : 쿠버네티스의 배포 가능한 가장 작은 단위

Replicaset : 레플리카 파드 집합의 실행을 항상 안정적 유지 (명시된 파드 개수에 대한 가용성 보증에 사용, Deployment 권장)

Deployment : Pod + Replicaset

Statefulset : Statefule을 관리하는 데 사용하는 워크로드, 파드들의 순서 및 고유성 보장, Deployment와 다르게 독자성 유지

Daemonset : 모든(or 일부) 노드가 파드의 사본을 실행 (노드가 클러스터에 추가되면 파드도 추가), 모든 노드에서 클러스터 스토리지 데몬 실행, 로그 수집 데몬 실행, 모니터링 데몬 실행

Job : 하나 이상의 파드 생성하고, 지정된 수의 파드가 성공적으로 종료될 때 까지 계속해서 파드의 실행을 재시도함(파드 병렬 실행 가능)

CronJob : 반복일정에 따라 Job을 생성, CronTab 파일의 한 줄과 같음

 

 

1일차 실습

microk8s install

alias kubectl='microk8s kubectl'

alias k='microk8s kubectl'

1. 클러스터 구성을 하여 마스터 노드 1, 워커 노드 2개의 환경 구성

• 먼저 control plane으로 설정할 노드에서 microk8s add-node 명령어를 사용하자

• 그러면 join 명령어를 사용하여 마스터 노드에 워커 노드를 등록할 수 있는 커맨드가 나온다.
  • microk8s join <MASTER_NODE_IP>:<PORT>/<NEW_TOKEN> --worker
  이것을 이용하여 다른 노드에서 이 커맨드를 입력하여 워커 노드로 등록하는 방식이다.

• 이런식으로 등록하면 밑에 다음과 같이 kakao-techbootcamp-eddy(마스터 노드) 밑에 2개의 워커노드가 생겼다.

• 여기서 말하는 노드의 기준은 매우 다양하다. (node == vm == ec2 등)

 

2. 쿠버네티스 오브젝트 배포 , 목적: 다양한 형태의 쿠버네티스 오브젝트를 배포

• 오브젝트를 사용하여 앱 배포해보기

오브젝트를 사용하여 배포를 할땐

모든 동작은 api 기반으로 동작한다. 같은 원리로 api-server 자체가 control plane에 의해 통제되기때문에

보통 우리가 보내는 요청은 control plane으로 보냄, 따라서 도착지는 worker node가 아니라 control plane이라고 보는게 맞다.

요청 보내는곳 -> control plane Pod같은 오브젝트가 뜨는 곳 -> worker node

그러면 apply하는건 master에서 한다? 처리를 worker에서 하고??

→ yes, apply는 master에서 하고 실제 리소스를 사용하면서 pod(컨테이너)가 실행되는 지점은 worker node이다.

• Pod object를 사용하여 배포해보기

# pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

이 yaml 파일을 작성하고 배포를 해보자~

kubectl apply -f pod.yaml

kubectl get pods

• Deployment object를 사용하여 배포해보기

# Deployment.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

같은 방식으로 yaml 파일 작성하고 apply를 통해 배포해보자!

• DaemonSet object 사용하여 배포하기

# DaemonSet.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-daemonset
  labels:
    app: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd

역시나 같은 방식으로 배포하자.

• Cronjob object 배포하기

cronjob → job → pod 배포형식을 확인하기

# job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: alpine
        command: ["echo", "-n", "helloooooo"]
      restartPolicy: Never
  backoffLimit: 4

# Cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

이제 Cronjob.yaml 파일을 apply 시켜주자!

그리고 위에서 말한 배포형식대로 쭉 확인해주자. 다음과 같다

 

kubectl get pods -o wide

이 커맨드를 통해 각 파드들이 어떤 노드에 배포되었는지 확인할수있다.

 

그럼 파드들이 어떠한 규칙(방식)으로 배포되는 것일까?

일반적으로 다음과 같은 규칙과 요인들이 Pod 스케줄링에 영향을 미친다.

1. Node Affinity/Anti-Affinity:
   • Node Affinity: 특정 노드에 Pod를 배포하도록 설정할 수 있습니다. 예를 들어, 특정 레이블을 가진 노드에만 Pod를 배포하도록 구성할 수 있습니다.
   • Node Anti-Affinity: 특정 노드에 Pod를 배포하지 않도록 설정할 수 있습니다.
2. Pod Affinity/Anti-Affinity:
   • Pod Affinity: 특정 레이블을 가진 다른 Pod와 같은 노드에 배포되도록 설정할 수 있습니다.
   • Pod Anti-Affinity: 특정 레이블을 가진 다른 Pod와 다른 노드에 배포되도록 설정할 수 있습니다.
3. Resource Requests and Limits:
   • 각 Pod는 CPU와 메모리에 대한 리소스 요청 및 제한을 가질 수 있습니다. 스케줄러는 이러한 요청을 기반으로 적절한 노드를 선택합니다.
4. Taints and Tolerations:
   • Taints: 노드에 적용될 수 있으며, 특정 조건을 만족하지 않는 Pod가 그 노드에 배포되는 것을 방지합니다.
   • Tolerations: Pod에 적용될 수 있으며, 특정 taint를 무시하고 해당 노드에 배포될 수 있도록 합니다.
5. DaemonSet:
   • DaemonSet은 클러스터의 각 노드에 하나의 Pod를 배포합니다. 이는 보통 로그 수집기, 모니터링 에이전트와 같은 애플리케이션에 사용됩니다.
6. Deployment and StatefulSet:
   • Deployment: 사용자가 지정한 수의 복제본이 실행되도록 보장합니다. 복제본은 기본적으로 클러스터의 노드들에 분산되어 배포됩니다.
   • StatefulSet: 상태를 가지는 애플리케이션을 배포하는 데 사용됩니다. 각 Pod는 고유한 정체성을 가지며, 순차적으로 배포 및 업그레이드됩니다.
7. Custom Schedulers:
   • Kubernetes는 기본 스케줄러 외에도 사용자가 정의한 스케줄러를 사용할 수 있도록 지원합니다. 사용자가 작성한 스케줄링 알고리즘을 통해 Pod를 특정 노드에 배포할 수 있습니다.
8. kubernetes 명령어에 익숙해지기. (정리)

생성 명령어

• kubectl create pods:
  • 사용자가 지정한 명세를 사용하여 새로운 Pod를 생성합니다. 그러나 일반적으로 직접적으로 Pods를 생성하기보다는 Deployment, StatefulSet 등을 사용하여 Pod를 관리하는 것이 더 일반적입니다.
• kubectl apply -f [filename]:
  • 지정된 파일의 설정을 적용하여 오브젝트를 생성하거나 업데이트합니다. 파일 내의 명세가 변경되었을 경우, 기존 오브젝트를 업데이트합니다.

확인 명령어

• kubectl get pods:
  • 현재 클러스터에서 실행 중인 Pod의 목록을 출력합니다. Pod의 상태, 이름, 재시작 횟수, 나이 등의 정보를 제공합니다.
• kubectl get namespaces:
  • 클러스터 내의 모든 네임스페이스(namespace)를 나열합니다. 각 네임스페이스는 클러스터 내에서 논리적인 분리 단위로 사용됩니다.

삭제 명령어

• kubectl delete pods [pod-name]:
  • 지정된 이름의 Pod를 삭제합니다. Pod가 삭제되면, 관련된 리소스(예: PersistentVolumeClaims 등)도 삭제될 수 있습니다. 만약 Deployment 또는 ReplicaSet에서 관리하는 Pod를 삭제할 경우, 새로운 Pod가 생성될 수 있습니다.

로그 확인 명령어

• kubectl logs [pod-name]:
  • 지정된 Pod에서 실행 중인 컨테이너의 로그를 출력합니다. Pod 내에 여러 컨테이너가 있을 경우, c [container-name] 옵션을 사용하여 특정 컨테이너의 로그를 볼 수 있습니다.

상세 정보 확인 명령어 (describe)

• kubectl describe [object-name]:
  • 지정된 오브젝트에 대한 자세한 정보를 출력합니다. Pod, Service, Deployment 등 다양한 오브젝트에 대해 사용할 수 있으며, 오브젝트의 상태, 이벤트, 설정 등을 상세히 보여줍니다.

리소스 사용량 확인 명령어 (top)

• kubectl top pod:
  • 클러스터 내의 Pod들이 사용 중인 CPU와 메모리 사용량을 출력합니다. 클러스터 리소스의 현재 상태를 모니터링하는 데 유용합니다.

오브젝트 수정 (Patch)

• kubectl patch pod:
  • 특정 필드를 업데이트하기 위해 사용.

ex) kubectl patch [object-type] [object-name] --type=json -p='[{"op": "replace", "path": "/spec/replicas", "value": 4}]'

Deployment 오브젝트의 replicas 필드를 4로 변경

Edit 명령어

• kubectl edit:
  • 전체 오브젝트 설정을 편집하기 위해 사용.

ex ) kubectl edit [object-type] [object-name]

nginx Deployment를 수정 → kubectl edit deployment nginx

이 명령어를 실행하면 텍스트 편집기가 열리고, 여기에서 Deployment의 설정을 편집할 수 있습니다. 저장하고 닫으면 변경 사항이 적용됩니다.

create <-> apply

• create는 새 오브젝트를 생성하고, apply는 오브젝트를 생성하거나 업데이트합니다.

log <-> describe

• logs는 특정 파드의 컨테이너 로그를 출력하고, describe는 오브젝트의 상세 정보를 출력합니다.

patch <-> edit

• patch는 특정 필드를 업데이트하고, edit는 전체 설정을 편집합니다.Kubernetes(K8s)k8s의 기능
  • 서비스 디스커버리와 로드 밸런싱
  • 스토리지 오케스트레이션
  • 자동화된 롤아웃과 롤백
  • 자동화된 빈 패킹
  • 자동화된 복구
  • 시크릿과 구성관리
  • 이 밖에도 여러가지 기능!