search

guswns1659 / guswns1659.github.io

MIT License
1 stars 0 forks source link

24.07.05 자료 준비 - kubelet의 위치만 남음 #13

Closed guswns1659 closed 2 months ago

guswns1659 commented 2 months ago

큰 개념

궁금한거 1순위

궁금한거 2순위

guswns1659 commented 2 months ago

팟

containers

guswns1659 commented 2 months ago

애노테이션과 라벨의 차이

Annotations과 Labels의 차이점

Annotations이 필요한 이유

  1. 메타데이터 저장:

    • 객체에 대한 부가적인 정보를 저장할 수 있습니다 (예: 생성 시간, 소유자, 빌드/배포 정보).

  2. 외부 도구와의 통합:

    • 모니터링 도구, 로그 관리 시스템 등 외부 도구와의 통합에 유용합니다.

  3. 자동화 및 스크립팅:

    • 자동화된 스크립트나 운영 도구에서 객체에 대한 추가 데이터를 저장하고 이를 기반으로 다양한 작업을 수행할 수 있습니다.

  4. 버전 관리 및 추적:

    • 객체의 버전 정보나 Git 커밋 해시 등을 저장하여 버전 관리 및 추적에 유용합니다.

  5. 객체 수명 주기 관리:

    • 객체의 생성 시간, 마지막 수정 시간 등 수명 주기 이벤트를 기록할 수 있습니다.
guswns1659 commented 2 months ago

서비스 어카운트

서비스 계정 요약

Kubernetes에서 서비스 계정(Service Account)은 파드가 API 서버와 상호작용할 때 사용하는 인증 수단입니다. 서비스 계정은 파드에 필요한 권한을 부여하고, 안전하게 API 서버와 통신할 수 있도록 합니다.

주요 역할

  1. API 서버와의 상호작용: 파드가 API 서버와 직접 통신하여 리소스를 관리하거나 클러스터 상태를 조회할 수 있습니다.
  2. 권한 관리: 서비스 계정을 통해 파드에 필요한 최소한의 권한만 부여하여 보안을 강화합니다.
  3. 자동 토큰 생성 및 주입: Kubernetes는 서비스 계정을 설정하면 자동으로 인증 토큰을 생성하고 파드 내에 주입합니다.
  4. 작업 분리: 여러 파드가 서로 다른 작업을 수행할 때, 각 파드에 별도의 서비스 계정을 할당하여 작업을 분리할 수 있습니다.

서비스 계정 설정 예시

  1. 서비스 계정 생성:

    apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: default

  2. 파드에 서비스 계정 할당:

    apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
serviceAccountName: my-service-account
containers:
- name: mycontainer
image: myimage

  3. Role과 RoleBinding을 통한 권한 부여:

    Role 생성:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

    RoleBinding 생성:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: default
subjects:
- kind: ServiceAccount
 name: my-service-account
 namespace: default
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

파드와 API 서버 간의 통신 사례

사례: 파드가 자신의 로그를 조회

파드 내부에서 실행되는 애플리케이션이 자신의 로그를 조회하기 위해 API 서버와 통신할 수 있습니다. 이때, 파드는 서비스 계정의 인증 토큰을 사용하여 API 서버와 안전하게 통신합니다.

인증 토큰 사용 예시

파드 내부에서 인증 토큰을 사용하여 API 서버와 통신할 때, 인증 토큰은 HTTP 요청의 Authorization 헤더에 포함됩니다. 예를 들어, Authorization: Bearer <토큰> 형식으로 사용됩니다.

요약된 흐름

  1. 서비스 계정 생성: 새로운 서비스 계정을 정의하고 생성합니다.
  2. 파드에 할당: 파드를 생성할 때 serviceAccountName 필드를 사용하여 서비스 계정을 할당합니다.
  3. 자동 토큰 주입: Kubernetes가 서비스 계정의 인증 토큰을 파드 내에 자동으로 주입합니다.
  4. 권한 부여: Role과 RoleBinding을 사용하여 서비스 계정에 필요한 권한을 부여합니다.
  5. 파드와 API 서버 통신: 파드는 주입된 토큰을 사용하여 API 서버와 안전하게 통신하고, 필요한 작업을 수행할 수 있습니다.
guswns1659 commented 2 months ago

qos

QoS 클래스 요약 및 스케줄링 예시

Kubernetes의 QoS 클래스(Quality of Service Class)는 파드의 자원 요청(request)과 자원 제한(limit)에 따라 파드의 우선순위를 결정하고, 클러스터 자원이 부족할 때 자원 할당의 우선순위를 결정합니다. QoS 클래스는 Guaranteed, Burstable, BestEffort의 세 가지로 나뉩니다.

QoS 클래스 종류 및 스케줄링 예시

1. Guaranteed 파드

2. Burstable 파드

3. BestEffort 파드

비교와 결론

limit을 초과할 경우

물론입니다. 자원 제한(limits)을 초과할 때 발생하는 상황만 남겨서 설명드리겠습니다.

자원 제한(limits)을 초과할 때 발생하는 상황

CPU 제한 초과

메모리 제한 초과

예시

CPU 제한 초과 예시

파드가 CPU 자원 제한을 초과하려고 할 때, 사용 가능한 CPU 자원 내에서 실행되도록 제한됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: cpu-limit-pod
spec:
  containers:
  - name: mycontainer
    image: myimage
    resources:
      requests:
        cpu: "500m"
      limits:
        cpu: "1"

메모리 제한 초과 예시

파드가 메모리 자원 제한을 초과하려고 할 때, 컨테이너가 종료되고 Kubernetes가 이를 재시작합니다.

apiVersion: v1
kind: Pod
metadata:
  name: memory-limit-pod
spec:
  containers:
  - name: mycontainer
    image: myimage
    resources:
      requests:
        memory: "128Mi"
      limits:
        memory: "256Mi"

결론

자원 제한을 적절히 설정하여 파드의 안정적인 동작을 보장하는 것이 중요합니다. 추가적인 질문이 있으시면 말씀해 주세요!

guswns1659 commented 2 months ago

tolerations

Tolerations와 Taints의 영어 단어 의미

Tolerations (톨러레이션)

Kubernetes에서 Tolerations는 파드가 특정 테인트(taint)를 가진 노드에서 실행될 수 있도록 허용하는 방법입니다. Tolerations와 taints는 함께 사용되어 특정 파드가 특정 노드에 스케줄링되는 것을 제어하는 중요한 메커니즘을 형성합니다. 이는 노드의 자원을 효율적으로 사용할 수 있게 하며, 특정 조건에서 파드를 격리하거나 우선순위를 설정하는 데 유용합니다.

테인트(Taints)와 톨러레이션(Tolerations)의 개념

테인트 예시

kubectl taint nodes <node-name> key=value:effect

톨러레이션(Tolerations) 예시

톨러레이션을 통해 파드가 특정 테인트를 무시하도록 설정할 수 있습니다. 톨러레이션은 파드의 스펙에 정의됩니다.

파드 정의 예시

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  containers:
  - name: mycontainer
    image: myimage

톨러레이션 필드

톨러레이션 효과

  1. NoSchedule:

    • 노드에 테인트가 있을 경우, 톨러레이션이 없는 파드는 해당 노드에 스케줄링되지 않습니다.
    • 톨러레이션이 있으면 파드가 해당 노드에 스케줄링될 수 있습니다.

  2. PreferNoSchedule:

    • 노드에 테인트가 있을 경우, 톨러레이션이 없는 파드는 가능한 한 해당 노드에 스케줄링되지 않도록 시도합니다.
    • 톨러레이션이 있으면 파드가 해당 노드에 스케줄링될 수 있습니다.

  3. NoExecute:

    • 노드에 테인트가 있을 경우, 톨러레이션이 없는 파드는 해당 노드에서 즉시 제거됩니다.
    • 톨러레이션이 있으면 파드는 해당 노드에서 계속 실행될 수 있습니다. tolerationSeconds 필드가 지정된 경우, 지정된 시간 동안만 파드가 해당 노드에 남아 있을 수 있습니다.

사용 예시

테인트 추가

kubectl taint nodes node1 key1=value1:NoSchedule

위 명령어는 node1에 key1=value1이라는 테인트를 추가하고, NoSchedule 효과를 적용합니다. 이는 톨러레이션이 없는 파드가 node1에 스케줄링되지 않도록 합니다.

톨러레이션 추가

파드가 해당 노드에 스케줄링될 수 있도록 톨러레이션을 추가합니다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  containers:
  - name: mycontainer
    image: myimage

위 설정은 key1=value1 테인트를 가진 노드에 NoSchedule 효과가 있어도 mypod가 스케줄링될 수 있도록 합니다.

요약

guswns1659 commented 2 months ago

volumes

Volumes (볼륨)

Kubernetes에서 볼륨은 파드 내 여러 컨테이너가 데이터를 공유할 수 있게 하거나, 파드가 종료되더라도 데이터를 지속적으로 저장할 수 있게 합니다. 볼륨은 컨테이너의 라이프사이클을 초과하여 데이터를 유지할 수 있으므로, 컨테이너 재시작, 재배포 등의 상황에서도 데이터를 보존하는 데 유용합니다.

볼륨의 주요 개념

  1. Ephemeral Volumes (휘발성 볼륨):

    • 파드의 라이프사이클 동안에만 존재하며, 파드가 삭제되면 볼륨도 삭제됩니다.
    • 예시: emptyDir, configMap, secret

  2. Persistent Volumes (영구 볼륨):

    • 파드의 라이프사이클을 초과하여 존재하며, 파드가 삭제되어도 데이터가 유지됩니다.
    • 예시: persistentVolumeClaim, hostPath

볼륨 종류 및 예시

1. emptyDir

2. hostPath

3. configMap

4. secret

5. persistentVolumeClaim

볼륨의 사용 시나리오

  1. 데이터 공유:

    • 동일한 파드 내 여러 컨테이너가 데이터를 공유할 필요가 있을 때 사용됩니다. 예를 들어, 로그 데이터를 공유하거나, 설정 파일을 공유할 때 유용합니다.

  2. 데이터 영속성:

    • 파드가 삭제되거나 재시작되더라도 데이터를 유지해야 하는 경우에 사용됩니다. 예를 들어, 데이터베이스의 데이터를 저장할 때 사용합니다.

  3. 설정 및 시크릿 관리:

    • ConfigMap이나 Secret을 사용하여 설정 데이터나 민감한 데이터를 컨테이너에 주입할 때 사용됩니다.

요약

guswns1659 commented 2 months ago

namespace와 resourceQuota

네임스페이스(Namespace)와 리소스 쿼터(Resource Quotas)

Kubernetes의 네임스페이스는 클러스터 내에서 논리적인 격리 단위를 제공하여 리소스를 그룹화하고 관리하는 데 사용됩니다. 네임스페이스는 여러 팀이나 프로젝트가 동일한 클러스터를 공유하면서도 리소스를 분리하고 관리할 수 있게 합니다. ResourceQuota는 특정 네임스페이스 내에서 사용할 수 있는 리소스의 총량을 제한하고 관리하는 데 사용됩니다.

네임스페이스의 주요 개념

  1. 리소스 격리:

    • 네임스페이스는 동일한 클러스터 내에서 리소스를 논리적으로 분리합니다. 이를 통해 서로 다른 프로젝트나 팀이 리소스를 충돌 없이 사용할 수 있습니다.

  2. 리소스 할당:

    • 네임스페이스는 리소스 할당과 제한을 적용할 수 있습니다. 이를 통해 각 네임스페이스에 할당된 자원을 관리할 수 있습니다.

  3. 액세스 제어:

    • 네임스페이스는 RBAC(Role-Based Access Control)와 결합하여 사용자가 특정 네임스페이스에 대한 접근 권한을 제어할 수 있습니다.

  4. 이름 충돌 방지:

    • 네임스페이스는 동일한 이름의 리소스가 서로 다른 네임스페이스에 존재할 수 있도록 하여 이름 충돌을 방지합니다.

Resource Quota의 주요 개념

  1. 네임스페이스 단위 적용:

    • ResourceQuota는 특정 네임스페이스 내에서 사용할 수 있는 리소스의 최대 값을 정의하여 네임스페이스 간의 자원 사용을 공정하게 관리합니다.

  2. 자원 사용 제한:

    • ResourceQuota를 통해 네임스페이스 내에서 사용할 수 있는 자원의 총량을 제한할 수 있습니다. 예를 들어, CPU, 메모리, 파드 수, 서비스 수 등을 제한할 수 있습니다.

예시

네임스페이스 생성

apiVersion: v1
kind: Namespace
metadata:
  name: mynamespace
kubectl apply -f namespace.yaml

ResourceQuota 설정

apiVersion: v1
kind: ResourceQuota
metadata:
  name: example-quota
  namespace: mynamespace
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "10"
    limits.memory: "16Gi"
kubectl apply -f resourcequota.yaml

파드의 Requests 및 Limits vs ResourceQuota의 Requests 및 Limits

파드의 Requests 및 Limits

ResourceQuota의 Requests 및 Limits

상호작용 및 제한 시나리오

  1. 파드 생성 및 자원 요청:

    • 네임스페이스 내에서 파드를 생성할 때, 파드의 자원 요청과 제한이 ResourceQuota의 제한을 초과하지 않는지 확인합니다.
    • 예를 들어, 네임스페이스의 ResourceQuota가 requests.memory: 8Gi로 설정된 경우, 네임스페이스 내 모든 파드의 자원 요청(memory)이 8Gi를 초과할 수 없습니다.

  2. 자원 요청 초과 시:

    • 만약 네임스페이스 내에서 새로운 파드가 생성될 때, 해당 파드의 자원 요청이 ResourceQuota의 제한을 초과하면 파드 생성이 실패합니다.

  3. 실행 중인 파드 자원 사용:

    • 파드가 실행 중일 때, 자원 제한을 초과하면 CPU 사용이 제한되거나, 메모리 사용이 초과될 경우 OOMKiller에 의해 컨테이너가 종료됩니다.

요약

guswns1659 commented 2 months ago

kubelet의 위치

팟이 아닌 노드에서 실행되는 에이전트로 노드에 접속해서 프로세스로 떠있다.

minikube 워커 노드에 접속한 뒤 kubelet이 떠 있는 상태를 확인

image