인그레스클래스 파라미터의 기본 범위는 클러스터 범위
.spec.parameters 필드만 설정하고 .spec.parameters.scope 필드는 지정하지 않거나,

.spec.parameters.scope 필드를 Cluster로 지정하면,

인그레스클래스는 클러스터 범위의 리소스를 참조

예시

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는
    # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다.
    # 이 정의는 쿠버네티스가 
    # 클러스터 범위의 파라미터 리소스를 검색하도록 한다.
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

네임스페이스

.spec.parameters 필드를 설정하고

.spec.parameters.scope 필드를 Namespace로 지정하면,

인그레스클래스는 네임스페이스 범위의 리소스를 참조
파라미터의 kind(+apiGroup)는 네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, 파라미터의 name은 namespace에 명시한 네임스페이스의 특정 리소스를 가리킴
네임스페이스 범위의 파라미터를 이용하여, 클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임 가능
클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당
- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 클러스터 운영 팀이 매번 승인
- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 RBAC 롤, 바인딩 등의 특별 접근 제어를 클러스터 운영자가 정의
인그레스클래스 API 자신은 항상 클러스터 범위
네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # 이 인그레스클래스에 대한 파라미터는 
    # "external-configuration" 환경 설정 네임스페이스에 있는
    # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

4. Generic ephemeral volumes

일반 임시 볼륨은 프로비저닝 후 일반적으로 비어 있는 스크래치 데이터에 대해 파드 별 디렉터리를 제공한다는 점에서 emptyDir 볼륨과 유사
하지만 다음과 같은 추가 기능도 제공
- 스토리지는 로컬이거나 네트워크 연결형(network-attached)일 수 있음
- 볼륨의 크기를 고정할 수 있으며 파드는 이 크기를 초과할 수 없음
- 드라이버와 파라미터에 따라 볼륨이 초기 데이터를 가질 수 있음
- 볼륨에 대한 일반적인 작업은 드라이버가 지원하는 범위 내에서 지원
  (스냅샷, 복제, 크기 조정, 및 스토리지 용량 추적 를 포함)

kind: Pod
apiVersion: v1
metadata:
  name: my-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/scratch"
        name: scratch-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: scratch-volume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: my-frontend-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi

5. Automatic Clean-up for Finished Jobs

완료-이후-TTL(TTL-after-finished) 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 제한하는 TTL (time to live) 메커니즘을 제공
TTL 컨트롤러는 잡만을 제어

완료-이후-TTL 컨트롤러

완료-이후-TTL 컨트롤러는 잡만을 지원
클러스터 운영자는 예시 와 같이 .spec.ttlSecondsAfterFinished 필드를 명시하여 완료된 잡(완료 또는 실패)을 자동으로 정리하기 위해 이 기능을 사용가능
잡의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), 완료-이후-TTL 컨트롤러는 해당 잡이 정리될 수 있다고 가정
완료-이후-TTL 컨트롤러가 잡을 정리할때 잡을 연속적으로 삭제
- 의존하는 오브젝트도 해당 잡과 함께 삭제되는 것을 의미
잡이 삭제되면 완료자(finalizers)와 같은 라이프 사이클 보증이 적용
TTL 초(sec)는 언제든지 설정이 가능
잡 필드 중 .spec.ttlSecondsAfterFinished 를 설정하는 몇 가지 예시
- 작업이 완료된 다음, 일정 시간 후에 자동으로 잡이 정리될 수 있도록 잡 메니페스트에 이 필드를 지정
- 이미 완료된 기존 잡에 이 새 기능을 적용하기 위해서 이 필드를 설정
- 어드미션 웹후크 변형 을 사용해서 잡 생성시 이 필드를 동적으로 설정, 클러스터 관리자는 이것을 사용해서 완료된 잡에 대해 TTL 정책을 적용
- 잡이 완료된 이후에 어드미션 웹후크 변형 을 사용해서 이 필드를 동적으로 설정, 잡의 상태, 레이블 등에 따라 다른 TTL 값을 선택

경고

TTL 초(sec) 업데이트

TTL 기간은, 예를 들어 잡의 .spec.ttlSecondsAfterFinished 필드는 잡을 생성하거나 완료한 후에 수정가능
그러나, 잡을 삭제할 수 있게 되면(TTL이 만료된 경우) 시스템은 TTL을 연장하기 위한 업데이트가 성공적인 API 응답을 리턴하더라도 작업이 유지되도록 보장하지 않는다.

시간 차이(Skew)

완료-이후-TTL 컨트롤러는 쿠버네티스 잡에 저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정
클러스터 간의 시간 차이에 민감, 시간 차이에 의해서 완료-이후-TTL 컨트롤러가 잘못된 시간에 잡 오브젝트를 정리가 될 수 도 있음

6. TTL mechanism for finished Jobs * 영문만 존재

한글 문서 업데이트가 안되긴 했지만, 바뀐 내용 버전(beta -> stable)외에 변경된 것외에 없음

완료된 잡 (Complete 또는 Failed)을 자동으로 정리하는 또 다른 방법
잡의 .spec.ttlSecondsAfterFinished 필드를 지정해서 완료된 리소스에 대해 TTL 컨트롤러에서 제공하는 TTL 메커니즘을 사용
TTL 컨트롤러는 잡을 정리하면 잡을 계단식으로 삭제
잡과 함께 파드와 같은 종속 오브젝트를 삭제
잡과 함께 파드와 같은 종속 오브젝트를 삭제

예시

pi-with-ttl 잡은 완료 후 100 초 이후에 자동으로 삭제

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

만약 필드를 0 으로 설정하면, 잡이 완료된 직후에 자동으로 삭제되도록 할 수 있음
만약 필드를 설정하지 않으면, 이 잡이 완료된 후에 TTL 컨트롤러에 의해 정리되지 않음

참고

AC2-1396 이슈와 관련된 내용

ttlSecondsAfterFinished 필드를 설정하는 것을 권장
이는 관리되지 않는 잡(직접 생성한, 크론잡 등 다른 워크로드 API를 통해 간접적으로 생성하지 않은 잡)의 기본 삭제 정책이 orphanDependents(관리되지 않는 잡이 완전히 삭제되어도 해당 잡에 의해 생성된 파드를 남겨둠)이기 때문
삭제된 잡의 파드가 실패하거나 완료된 뒤 컨트롤 플레인이 언젠가 가비지 콜렉션을 한다고 해도, 이렇게 남아 있는 파드는 클러스터의 성능을 저하시킴
최악의 경우에는 이 성능 저하로 인해 클러스터가 중단
리밋 레인지(Limit Range)와 리소스 쿼터를 사용하여 특정 네임스페이스가 사용할 수 있는 자원량을 제한하는 것도 방법

7. Dual-stack support with kubeadm

IPv4/IPv6 이중 스택이 활성화된 쿠버네티스 클러스터들을 어떻게 검증하는지 설명
v1.23 이전 버전에서도 검증을 수행할 수 있지만 GA 기능으로만 제공되며, v1.23부터 공식적으로 지원

자세한 내용은 링크 참조

Configure volume permission and ownership change policy for Pods * 영문만 존재

Pods에 대한 볼륨 사용 권한 및 소유권 변경 정책 구성
기본적으로 Kubernetes는 볼륨이 마운트될 때 각 볼륨의 컨텐츠에 대한 소유권과 사용 권한을 포드 SecurityContext에 지정된 fsGroup과 일치하도록 반복적으로 변경
대규모 볼륨의 경우 소유권 및 사용 권한을 확인하고 변경하는 데 많은 시간이 소요되어 포드 시작 속도가 느려질 수 있음
SecurityContext 내에서 fsGroupChangePolicy 필드를 사용하여 Kubernetes가 볼륨에 대한 소유권 및 사용 권한을 확인하고 관리하는 방법을 제어가 가능

fsGroupChangePolicy

fsGroupChangePolicy는 포드 내부에 expose 되기 전에 볼륨의 소유권 및 사용 권한을 변경하는 동작을 정의
이 필드는 fsGroup 제어 소유권 및 사용 권한을 지원하는 볼륨 유형에만 적용
이 필드에는 두 가지 값이 존재
- OnRootMismatch: 루트 디렉터리의 권한 및 소유권이 볼륨의 예상 권한과 일치하지 않는 경우만 변경, 이렇게 하면 볼륨의 소유권과 사용 권한을 변경하는 데 걸리는 시간을 단축가능
- Always: 볼륨 마운트되면 항상 볼륨의 사용 권한 및 소유권을 변경

예시.

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

이 필드는 secret, configMap 및 emptydir와 같은 사용 후 삭제 볼륨 유형에는 영향 X

9. Horizontal Pod Autoscaling

stable로 변경된 기능 3가지

사용자 정의 메트릭을 이용하는 스케일링

이전에는 autoscaling/v2beta2 API 버전이 이 기능을 베타 기능으로 제공
autoscaling/v2beta2 API 버전을 사용하는 경우, (쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은) 커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있음, 이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회
요구 사항에 대한 정보는 메트릭 API를 위한 지원을 참조

복수의 메트릭을 이용하는 스케일링

이전에는 autoscaling/v2beta2 API 버전이 이 기능을 베타 기능으로 제공
autoscaling/v2 API 버전을 사용하는 경우, HorizontalPodAutoscaler는 스케일링에 사용할 복수의 메트릭을 설정 가능
- 이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안
- HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를 조정
  (이 값이 이전에 설정한 ‘총 최대값(overall maximum)’보다는 크지 않을 때에만)

구성가능한 스케일링 동작

이전에는 autoscaling/v2beta2 API 버전이 이 기능을 베타 기능으로 제공
v2 버전의 HorizontalPodAutoscaler API를 사용한다면, behavior 필드(API 레퍼런스 참고)를 사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성가능
각 방향에 대한 동작은 behavior 필드 아래의 scaleUp / scaleDown를 설정하여 지정가능
stabilizationWindow 를 명시하여 스케일링 목적물의 레플리카 수 워크로드 스케일링의 안정성을 고려할 수 있음

스케일링 정책

스펙의 behavior 섹션에 하나 이상의 스케일링 정책을 지정
정책이 여러 개 지정된 경우 가장 많은 양의 변경을 허용하는 정책이 기본적으로 선택된 폴리시

스케일 다운 예시

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

periodSeconds 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타냄
첫 번째 정책은 (파드들) 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용
두 번째 정책은 비율 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용
기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은 파드의 레플리카 수가 40개를 초과하는 경우에만 사용
레플리카가 40개 이하인 경우 첫 번째 정책이 적용
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는 경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운
레플리카의 수가 72개일 때 다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림
오토스케일러 컨트롤러의 각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산
레플리카의 수가 40 미만으로 떨어지면 첫 번째 폴리시 (파드들) 가 적용되고 한번에 4개의 레플리카가 줄어듬

확장 방향에 대해 selectPolicy 필드를 확인하여 폴리시 선택을 변경 가능
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 최소(Min)로 값을 설정
값을 Disabled 로 설정하면 해당 방향으로 스케일링이 완전히 비활성화

stabilizationWindow

stabilizationWindow는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카 수의 안정성을 위해 사용
오토스케일링 알고리즘은 이전의 목표 상태를 추론하고 워크로드 수의 원치 않는 변화를 방지하기 위해 이stabilizationWindow를 활용

scaleDown에 대해 안정화 윈도우 예시

1
2
3

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우, 알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용
위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 됨
이를 통해 동적 최대값(rolling maximum)을 근사화하여, 스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지

기본 동작

사용자 지정 스케일링을 사용하기 위해서 모든 필드를 지정하지 않아도 됨
사용자 정의가 필요한 값만 지정 가능
이러한 사용자 지정 값은 기본값과 병합
기본값은 HPA 알고리즘의 기존 동작과 동일

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

스케일링 다운의 경우 300 초 (또는 제공된 경우–horizontal-pod-autoscaler-downscale-stabilization 플래그의 값
스케일링 다운에서는 현재 실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 존재하며 이는 스케일링 대상을 최소 허용 레플리카로 축소할 수 있음을 의미
스케일링 업에는 stabilizationWindow가 없다
메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업을 한다.
- 두 가지 폴리시가 존재
  - HPA가 정상 상태에 도달 할 때까지 15초 마다 4개의 파드
  - 또는 현재 실행 중인 레플리카의 100% 가 추가된다.

예시: 다운스케일 stabilizationWindow 변경

사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해 다음 동작이 HPA에 추가

1
2
3

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

예시: 스케일 다운 속도 제한

HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해 다음 동작이 HPA에 추가

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소 정책을 추가하고, selectPolicy 를 최소로 설정
selectPolicy 를 Min 으로 설정하면 자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60
    - type: Pods
      value: 5
      periodSeconds: 60
    selectPolicy: Min

예시: 스케일 다운 비활성화

selectPolicy 의 Disabled 값은 주어진 방향으로의 스케일링을 끔
따라서, 다운 스케일링을 방지하기 위해 다음 폴리시가 사용

1
2
3

behavior:
  scaleDown:
    selectPolicy: Disabled

1.23 버전 변경된 리소스

추가 io.k8s.api.apps.v1.StatefulSetPersistentVolumeClaimRetentionPolicy
변경 io.k8s.api.apps.v1.StatefulSetSpec
- 추가 persistentVolumeClaimRetentionPolicy
추가 io.k8s.api.autoscaling.v2.ContainerResourceMetricSource
변경 io.k8s.api.batch.v1.JobStatus
- 추가 ready
추가 io.k8s.api.core.v1.GRPCAction
제거 io.k8s.api.core.v1.Handler
추가 io.k8s.api.core.v1.LifecycleHandler
변경 io.k8s.api.core.v1.PersistentVolumeClaimStatus
- 추가 allocatedResources
추가 io.k8s.api.core.v1.PodOS
추가 io.k8s.api.core.v1.PodSpec
- 추가 os
변경 io.k8s.api.core.v1.Probe
- 추가 grpc
추가 io.k8s.api.flowcontrol.v1beta2.FlowDistinguisherMethod
추가 io.k8s.api.flowcontrol.v1beta2.FlowSchema
제거 io.k8s.api.rbac.v1alpha1.AggregationRule
제거 io.k8s.api.rbac.v1alpha1.ClusterRole
제거 io.k8s.api.scheduling.v1alpha1.PriorityClass
제거 io.k8s.api.storage.v1alpha1.VolumeAttachment
제거 io.k8s.api.storage.v1alpha1.VolumeAttachmentList
제거 io.k8s.api.storage.v1alpha1.VolumeAttachmentSource
제거 io.k8s.api.storage.v1alpha1.VolumeAttachmentStatus
제거 io.k8s.api.storage.v1alpha1.VolumeError
추가 io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1.ValidationRule

1.23 버전 변경된 k8s-apiserver

변경 /api/v1/namespaces/{namespace}/services
- method: delete
추가 /apis/autoscaling/v2/
- methods: get
추가 /apis/autoscaling/v2/horizontalpodautoscalers
- methods: get
추가 /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers
- methods: delete, get, post
추가 /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}
- methods: delete, get, patch, put
추가 /apis/autoscaling/v2/namespaces/{namespace}/horizontalpodautoscalers/{name}/status
- methods: get, patch, put
추가 /apis/autoscaling/v2/watch/horizontalpodautoscalers
- methods: get
추가 /apis/autoscaling/v2/watch/namespaces/{namespace}/horizontalpodautoscalers
- methods: get
추가 /apis/autoscaling/v2/watch/namespaces/{namespace}/horizontalpodautoscalers/{name}
- methods: get
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/
- methods: get
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas
- methods: delete, get, post
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}
- methods: delete, get, patch, put
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}/status
- methods: get, patch, put
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations
- methods: delete, get, post
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}
- methods: delete, get, patch, put
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}/status
- methods: get, patch, put
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/watch/flowschemas
- methods: get
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/watch/flowschemas/{name}
- methods: get
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/watch/prioritylevelconfigurations
- methods: get
추가 /apis/flowcontrol.apiserver.k8s.io/v1beta2/watch/prioritylevelconfigurations/{name}
- methods: get
제거 /apis/rbac.authorization.k8s.io/v1alpha1/
제거 /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles
제거 /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/rolebindings/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles
제거 /apis/rbac.authorization.k8s.io/v1alpha1/namespaces/{namespace}/roles/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/rolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/roles
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/rolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/rolebindings/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/roles
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/namespaces/{namespace}/roles/{name}
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/rolebindings
제거 /apis/rbac.authorization.k8s.io/v1alpha1/watch/roles
제거 /apis/scheduling.k8s.io/v1alpha1/
제거 /apis/scheduling.k8s.io/v1alpha1/priorityclasses
제거 /apis/scheduling.k8s.io/v1alpha1/priorityclasses/{name}
제거 /apis/scheduling.k8s.io/v1alpha1/watch/priorityclasses
제거 /apis/scheduling.k8s.io/v1alpha1/watch/priorityclasses/{name}
변경 /apis/storage.k8s.io/v1alpha1/namespaces/{namespace}/csistoragecapacities/{name}
제거 /apis/storage.k8s.io/v1alpha1/volumeattachments/{name}
제거 /apis/storage.k8s.io/v1alpha1/watch/volumeattachments
제거 /apis/storage.k8s.io/v1alpha1/watch/volumeattachments/{name}