개요

아래 강의를 듣고 정리했습니다.

• https://learn.kodekloud.com/user/courses/certified-kubernetes-security-specialist-cks

API 우선순위 및 공정성

Kubernetes에서는 모든 리소스 관리 작업을 단일 API로 처리합니다.

API는 애플리케이션 생성, 확장, 배포 업데이트 요청을 관리하는 중심점입니다.

다중 테넌트에서는 애플리케이션 중요도가 각기 다르기에 필수적인 API 요청에 우선순위를 두는 것이 좋습니다.

API 우선순위 구성

flowcontrol.apiserver.k8s.io/v1beta3 다음 API를 사용하여 우선순위 수준 구성을 정의합니다.

• high-priority → 더 높은 동시성을 설정
  • 모든 요청이 Queue로 들어가 더 많은 요청을 꺼내서 처리 → 지연되지 않도록 보장

apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: PriorityLevelConfiguration
metadata:
  name: high-priority
spec:
  type: Limited
  limited:
    assuredConcurrencyShares: 10  # High priority gets more concurrency
    limitResponse:
      type: Queue
---
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: PriorityLevelConfiguration
metadata:
  name: low-priority
spec:
  type: Limited
  limited:
    assuredConcurrencyShares: 1  # Low priority gets less concurrency
    limitResponse:
      type: Queue

apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: FlowSchema
metadata:
  name: high-priority-namespace-a
spec:
  priorityLevelConfiguration:
    name: high-priority  # Link to high priority
    matchingPrecedence: 1000
  rules:
    - subjects:
        - kind: ServiceAccount
          name: "system-account"  # Alternatively, match on user or service account
          namespace: "namespace-a"  # Target Namespace A
      resourceRules:
        - verbs: ["*"]
          apiGroups: ["*"]
          resources: ["*"]


---
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: FlowSchema
metadata:
  name: low-priority-namespace-b
spec:
  priorityLevelConfiguration:
    name: low-priority  # Link to low priority
    matchingPrecedence: 2000
  rules:
    - subjects:
        - kind: Group
          name: "regular-users"
        - kind: ServiceAccount
          name: "default"
          namespace: "namespace-b"  # Target Namespace B
      resourceRules:
        - verbs: ["*"]
          apiGroups: ["*"]
          resources: ["*"]

• namespace-a에 있는 system-account라는 ServiceAccount가 모든 동작에서 high-priority PriorityLevelConfiguration을 적용
• regular-users 그룹이나, namespace-b의 default ServiceAccount가 low-priority 로 처리

Pod 우선순위 및 선점

리소스가 부족한 상황에서 중요도 높은 파드가 필요한 리소스를 확보할 수 있도록 보장합니다. Namespace A에서 실행 중인 파드가 지속적인 운영(가용성) 및 리소스가 필요하다면 B에 영향을 주면서도 우선순위 선점을 통해 리소스 할당을 받을 수 있습니다.

Pod 우선순위 구성

• PriorityClass를 적용합니다.
  • 높은 우선순위는 더 큰 값을 받아 할당됩니다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000  # High priority for critical workloads
globalDefault: false
description: "This priority class is for critical production workloads."
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100  # Low priority for non-critical tasks
globalDefault: false
description: "This priority class is for non-critical development workloads."

파드에는 더 높은 우선순위를 적용합니다.

apiVersion: v1
kind: Pod
metadata:
  name: critical-app
  namespace: namespace-a
spec:
  priorityClassName: high-priority
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "500Mi"
        cpu: "500m"
      limits:
        memory: "500Mi"
        cpu: "500m"

API 우선순위와 Pod 우선순위 차이

<API Priority & Fairness>

Kubernetes API 요청 흐름과 제어.

우선 순위가 낮은 리소스 생성 요청으로 우선 순위 높은 리소스가 생성 못하는 현상 방지

<Pod Priority & Preemption>

노드 수준의 리소스 할당

스케줄링 우선 순위를 조절하여 낮은 우선순위의 Pod를 제거하여 동작하게 만듦

QoS(Quality of Service)

파드 리소스 요청 및 제한에 따라 서로 다른 QoS로 구분

예측 가능한 리소스 가용성을 보장하며 특정 테넌트가 클러스터 리소스를 독점하는 것을 방지

Guaranteed QoS

Pod의 CPU, Memory를 Limit과 Request를 동일하게 설정한다면 Guaranteed QoS입니다.

Pod가 항상 지정된 리소스를 확보하도록 보장합니다.

apiVersion: v1
kind: Pod
metadata:
  name: critical-app
  namespace: namespace-a
spec:
  containers:
    - name: critical-container
      image: nginx
      resources:
	      request: 
	        memory: "500Mi"
	        cpu: "500m"
        limits:
          memory: "500Mi"
          cpu: "500m"

Burstable QoS

리소스 요청 값을 제한 값보다 낮게 설정하면 Pod는 Burstable 클래스입니다.

• 최소 500Mi, 200m CPU → 최대 16Gi, 1 CPU

apiVersion: v1
kind: Pod
metadata:
  name: critical-app
  namespace: namespace-a
spec:
  containers:
    - name: critical-container
      image: nginx
      resources:
        request:
	        memory: "500Mi"
	        cpu: "500m"
	      limits:
	        memory: "16Gi"
	        cpu: "1"

Best-Effort QoS

리소스를 보장받지 못하고 사용 가능할 때만 리소스를 사용합니다.

리소스가 부족해진다면 Best Effort Pod는 Evict 될 가능성이 높습니다.

Network QoS

네트워크는 QoS를 Native로 제공하지 않습니다.

다만 Calico같은 CNI를 활용하는 경우 Traffice Control이 가능합니다.

• calico API → limits → rate

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: tenant-a-network-policy
  namespace: namespace-a
spec:
  selector: all()  # Apply to all pods in Namespace A
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports: [80]
      limits:
        rate: 10Mbps  # Limit ingress traffic to 10Mbps for tenant pods
  egress:
    - action: Allow
      protocol: TCP
      destination:
        ports: [80]
      limits:
        rate: 10Mbps  # Limit egress traffic to 10Mbps for tenant pods

Storage QoS

스토리지 QoS는 볼륨에서 수행할 수 있는 IOPS를 제어합니다. 높은 디스크 성능이 필요한 경우 중요하며 StorageClass와 스토리지 플랫폼에서 기본 QoS 기능을 제공하여 간접적으로 지원합니다.

• 전용으로 만드는 것과 동일..
  • 단일 AZ 환경: Immediate
  • 멀티 AZ 환경 : WaitForFirstConsumer (권장)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: high-performance
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1            # AWS io1 disks support high IOPS
  iopsPerGB: "50"      # Specify high IOPS per GB
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate