Kubernetes 기술 개념 정리 7

44.  Kubernetes 워커 노드가 클러스터에 가입하는 과정

Kubernetes 워커 노드를 확장하는 경우, 애플리케이션 시스템의 수평 확장을 위해 워커 노드를 추가해야 합니다. 주요 과정은 다음과 같습니다:

1. 해당 노드에 Docker, kubelet, kube-proxy 서비스를 설치합니다.
2. kubelet과 kube-proxy의 시작 매개변수를 설정하고, Master URL을 현재 Kubernetes 클러스터의 Master 노드 주소로 지정한 뒤, 이 서비스를 시작합니다.
3. kubelet의 기본 자동 등록 메커니즘을 통해, 새로운 워커 노드는 기존 Kubernetes 클러스터에 자동으로 가입됩니다.
4. Kubernetes Master는 새로운 워커 노드의 등록 요청을 수락한 후, 해당 노드를 현재 클러스터의 스케줄링 범위에 자동으로 포함시킵니다.

45. Kubernetes Requests와 Limits가 Pod 스케줄링에 미치는 영향

Pod가 생성되면 Kubernetes 스케줄러(Scheduler)는 해당 Pod를 실행할 노드를 선택합니다. CPU와 메모리와 같은 각 계산 리소스에 대해, 각 노드에는 Pod 실행에 사용할 수 있는 최대 용량 값이 존재합니다.

스케줄러는 스케줄링 과정에서, 해당 노드에 있는 모든 Pod의 CPU 및 메모리 Requests 총합이, 해당 노드가 Pod에 제공할 수 있는 CPU와 메모리 최대 용량을 초과하지 않는지 확인합니다. 이를 통해 Pod가 안정적으로 실행될 수 있도록 보장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: resource-example
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "64Mi"      # 최소 요청 메모리: 64MiB
        cpu: "250m"         # 최소 요청 CPU: 250m (0.25 vCPU)
      limits:
        memory: "128Mi"     # 최대 허용 메모리: 128MiB
        cpu: "500m"         # 최대 허용 CPU: 500m (0.5 vCPU)

1. requests:
   • Pod가 최소한으로 필요한 리소스입니다.
   • 이 값에 따라 Kubernetes는 Pod를 실행할 노드를 결정합니다.
   • 예: Pod는 최소 64Mi 메모리와 **0.25 vCPU(250m)**를 사용할 수 있는 노드에 스케줄링됩니다.
2. limits:
   • Pod가 사용할 수 있는 최대 리소스입니다.
   • Pod가 이 값을 초과하면 CPU는 제한되고, 메모리는 OOM(Out Of Memory) 오류로 인해 Pod가 종료될 수 있습니다.
   • 예: Pod는 최대 128Mi 메모리와  0.5 vCPU(500m) 를 사용할 수 있습니다.

46.  Kubernetes Metric Service 간단 설명

Kubernetes는 1.10 버전부터 Metrics Server를 기본적인 성능 데이터 수집 및 모니터링 도구로 채택하였습니다. Metrics Server는 핵심 지표(Core Metrics)를 제공하며, 여기에는 다음과 같은 항목이 포함됩니다:

• 노드(Node): CPU 및 메모리 사용량.
• 파드(Pod): CPU 및 메모리 사용량.

사용 사례:

• Horizontal Pod Autoscaler(HPA): Pod의 수평적 확장을 위한 CPU 및 메모리 메트릭 제공.
• 리소스 사용량 모니터링: 클러스터 내의 리소스 상태를 실시간으로 확인.

기타 지표 (Custom Metrics)

Metrics Server는 기본적인 지표만 제공하며, **사용자 정의 지표(Custom Metrics)**와 같은 고급 모니터링은 Prometheus와 같은 추가적인 모니터링 도구를 통해 수행됩니다.

Prometheus는 애플리케이션 수준의 상세한 지표와 경고(alert) 설정을 지원하여 Kubernetes 환경에서 종합적인 모니터링을 가능하게 합니다.

 

47. Kubernetes에서 노드를 우아하게 종료하고 유지 관리하는 방법

Kubernetes 노드는 많은 Pod를 실행하고 있으므로, 노드를 종료하기 전에 먼저 kubectl drain 명령어를 사용하여 해당 노드에서 실행 중인 Pod를 퇴거시키는 것이 권장됩니다. 그런 다음 노드를 종료하고 유지 보수를 진행할 수 있습니다.

1. 노드에서 Pod를 안전하게 퇴거(draining)

kubectl drain 명령을 사용해 특정 노드에서 실행 중인 Pod를 다른 노드로 이동시킵니다.

kubectl drain <노드 이름> --ignore-daemonsets --delete-emptydir-data

 

• --ignore-daemonsets: DaemonSet Pod는 퇴거하지 않습니다.
• --delete-emptydir-data: emptyDir 볼륨을 사용하는 Pod도 삭제됩니다.

Drain의 중요성

• Pod를 안전하게 다른 노드로 이동하여 서비스 중단을 최소화.
• Kubernetes가 클러스터 상태를 원활하게 유지하도록 돕는 과정.

 

48.Kubernetes 클러스터 페더레이션(Kubernetes Cluster Federation) 간단 설명

Kubernetes 클러스터 페더레이션은 여러 개의 Kubernetes 클러스터를 하나의 클러스터처럼 통합 관리할 수 있도록 해주는 기능입니다. 이를 통해, 하나의 데이터 센터나 클라우드 환경 내에서 여러 Kubernetes 클러스터를 생성하고, 클러스터 페더레이션을 사용해 한 곳에서 모든 클러스터를 제어 및 관리할 수 있습니다.

 

49. 컨테이너와 호스트에 애플리케이션을 배포하는 차이점

컨테이너의 핵심 개념은 다음과 같습니다:

1. 초고속 시작(초 단위):
   • 컨테이너는 초 단위로 애플리케이션을 시작할 수 있으며, 이는 호스트에 직접 애플리케이션을 배포하는 방식으로는 달성할 수 없는 장점입니다.
2. 한 번 패키징하여 어디서나 실행 가능:
   • 컨테이너는 **"한 번 패키징, 어디서나 실행"**이라는 철학을 따릅니다.

하지만, 컨테이너 사용 시 데이터의 지속성 문제에 더욱 주의를 기울여야 합니다.

또한, 컨테이너 배포의 또 다른 핵심 개념은 각 서비스를 서로 독립적으로 격리하여, 한 서비스가 다른 서비스에 영향을 미치지 않도록 한다는 점입니다.

 

50.  롤링 업데이트(rolling update) 과정 제어 방법

아래 명령어를 사용하면 롤링 업데이트 과정에서 제어할 수 있는 파라미터를 확인할 수 있습니다

kubectl explain deploy.spec.strategy.rollingUpdate

 

maxSurge

• 설명: 롤링 업데이트 중 생성할 수 있는 추가 Pod 수의 상한을 설정합니다.
  • 값은 **퍼센트(%)**나 정수로 지정할 수 있습니다.
  • 기본값은 1입니다.
• 예시:
  maxSurge 값이 3으로 설정된 경우, 기존 Pod를 대체할 새로운 Pod를 최대 3개까지 추가 실행합니다.
  • 즉, 최대 Pod 수가 기존의 기대치보다 3개 많아질 수 있습니다.

maxUnavailable

• 설명: 롤링 업데이트 중 비활성화된 Pod 수의 상한을 설정합니다.
  • maxSurge와는 관계없이 동작합니다.
• 예시:
  Pod가 10개 있을 때, maxUnavailable 값을 3으로 설정하면 최대 3개의 Pod가 비활성 상태가 되는 것을 허용합니다.
  • 업데이트 과정에서 비활성 Pod 수가 3개 이하라면 업데이트가 계속 진행됩니다.

이 두 가지 파라미터를 적절히 설정하면, 롤링 업데이트 시 애플리케이션의 가용성과 업데이트 속도를 효율적으로 관리할 수 있습니다.

 

51. 이미지 상태의 종류

1. Running: Pod에 필요한 컨테이너가 성공적으로 노드에 스케줄링되었으며, 이미 실행 중인 상태입니다.

2. Pending: API 서버가 Pod 리소스 객체를 생성하여 etcd에 저장했지만, 아직 스케줄링되지 않았거나 이미지를 다운로드 중인 상태입니다.

3. Unknown: API 서버가 Pod 객체의 상태를 정상적으로 가져올 수 없는 상태입니다. 보통 API 서버가 해당 워커 노드의 kubelet과 통신할 수 없을 때 발생합니다.