Merge pull request #36922 from Seo-yul/dev-1.25-ko.1-Outdated-M90-M126

[ko] Update outdated files dev-1.25-ko.1 (M90-M126)

content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -9,12 +9,9 @@ weight: 10
 
 <!-- overview -->
 
-쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다.
+{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용하여
-이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다.
+{{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 시간 기반의 스케줄에 따라 실행할 수 있다.
-이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다.
+이러한 자동화된 잡은 리눅스 또는 유닉스 시스템의 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
-
-시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
-이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
 
 크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
 크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
@@ -25,15 +22,10 @@ weight: 10
 
 제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}}
 
-
-
 <!-- steps -->
 
 ## 크론잡(CronJob) 생성 {#creating-a-cron-job}
@@ -96,8 +88,7 @@ NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
 hello   */1 * * * *   False     0        50s             75s
 ```
 
-크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지 
+크론 잡 `hello` 가 `LAST SCHEDULE` 열에 명시된 시간에 잡을 성공적으로 스케줄링한 것을 볼 수 있다.
-`LAST SCHEDULE`에서 확인해야 한다. 
 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
 
 이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
@@ -135,19 +126,25 @@ kubectl delete cronjob hello
 
 ## 크론잡(CronJob) 명세 작성 {#writing-a-cron-job-spec}
 
-다른 모든 쿠버네티스 오브젝트들과 마찬가지로, 크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. Kubernetes 개체 작업과 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 대한 자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
+다른 모든 쿠버네티스 오브젝트들과 마찬가지로,
+크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다.
+쿠버네티스 오브젝트 및 그 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 다루기에 대한
+자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
 [kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
 
 크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
 
 {{< note >}}
-크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
+크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다.
+이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다.
+즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
 {{< /note >}}
 
 ### 스케줄
 
 `.spec.schedule` 은 `.spec` 의 필수 필드이다.
-이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
+이 필드는 `0 * * * *` 또는 `@hourly`와 같은 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아, 
+해당 잡이 생성 및 실행될 스케줄 시간으로 설정한다.
 
 이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은
 [FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
@@ -160,13 +157,15 @@ kubectl delete cronjob hello
 > "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
 
 {{< note >}}
-스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
+스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며,
+주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
 {{< /note >}}
 
 ### 잡 템플릿
 
 `.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
-이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
+이것은 중첩되어(nested) 있고 `apiVersion` 이나 `kind` 가 없다는 것을 제외하면,
+[잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
 잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
 
 ### 시작 기한
@@ -178,10 +177,11 @@ kubectl delete cronjob hello
 이 필드를 지정하지 않으면, 잡에 기한이 없다.
 
 `.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
-크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
+크론잡 컨트롤러는 예상 잡 생성 시각과 현재 시각의 차이를 측정하고,
 시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
 
-예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.
+예를 들어, `200` 으로 설정되었다면,
+예상 잡 생성 시각으로부터 200초까지는 잡이 생성될 수 있다.
 
 ### 동시성 정책
 
@@ -190,8 +190,10 @@ kubectl delete cronjob hello
 명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
 
 * `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
-* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
+* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다.
-* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
+  새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
+* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우,
+  크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
 
 참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
 크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
@@ -205,11 +207,13 @@ kubectl delete cronjob hello
 
 {{< caution >}}
 스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
-[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
+[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면,
+누락된 잡들이 즉시 스케줄된다.
 {{< /caution >}}
 
 ### 잡 히스토리 한도
 
 `.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
 이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
-기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
+기본적으로, 각각 3과 1로 설정된다.
+한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.

content/ko/docs/tasks/job/indexed-parallel-processing-static.md

@@ -19,7 +19,7 @@ weight: 30
 파드 인덱스는 10진수 값을 문자열로 표현한 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
 `batch.kubernetes.io/job-completion-index` 를 통해
 사용할 수 있다. 컨테이너화된 태스크 프로세스가 이 인덱스 정보를 가져갈 수 있도록,
-[downward API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+[다운워드(downward) API](/ko/docs/concepts/workloads/pods/downward-api/)
 메커니즘을 사용하여 어노테이션의 값을 발행할 수 있다.
 편의상, 컨트롤 플레인은 downward API를 자동 설정하여
 `JOB_COMPLETION_INDEX` 환경변수에 인덱스를 노출할 수 있도록 한다.

content/ko/docs/tasks/manage-daemon/update-daemon-set.md

@@ -39,7 +39,7 @@ weight: 10
 [`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
 (기본값은 0),
 [`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
-(베타 기능, 기본값은 0)를 
+(기본값은 0)를
 설정할 수도 있다.
 
 ### `RollingUpdate` 업데이트 전략으로 데몬셋 생성

content/ko/docs/tasks/manage-gpus/scheduling-gpus.md

@@ -6,8 +6,6 @@ title: GPU 스케줄링
 description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다.
 ---
 
-
-
 <!-- overview -->
 
 {{< feature-state state="beta" for_k8s_version="v1.10" >}}
@@ -65,7 +63,7 @@ spec:
   containers:
     - name: cuda-vector-add
       # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
-      image: "k8s.gcr.io/cuda-vector-add:v0.1"
+      image: "registry.k8s.io/cuda-vector-add:v0.1"
       resources:
         limits:
           nvidia.com/gpu: 1 # GPU 1개 요청하기
@@ -208,7 +206,7 @@ spec:
   containers:
     - name: cuda-vector-add
       # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
-      image: "k8s.gcr.io/cuda-vector-add:v0.1"
+      image: "registry.k8s.io/cuda-vector-add:v0.1"
       resources:
         limits:
           nvidia.com/gpu: 1

content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md

@@ -86,20 +86,12 @@ metadata:
   name: example-configmap-1-8mbdf7882g
 ```
 
-env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다.
+env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
-
-{{< note >}}
-로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다.
-{{< /note >}}
-
-다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
 
 ```shell
 # .env 파일 생성
-# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다
 cat <<EOF >.env
 FOO=Bar
-BAZ
 EOF
 
 cat <<EOF >./kustomization.yaml
@@ -113,7 +105,7 @@ EOF
 생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
 
 ```shell
-BAZ=Qux kubectl kustomize ./
+kubectl kustomize ./
 ```
 
 생성된 컨피그맵은 다음과 같다.
@@ -121,11 +113,10 @@ BAZ=Qux kubectl kustomize ./
 ```yaml
 apiVersion: v1
 data:
-  BAZ: Qux
   FOO: Bar
 kind: ConfigMap
 metadata:
-  name: example-configmap-1-892ghb99c8
+  name: example-configmap-1-42cfbf598f
 ```
 
 {{< note >}}
@@ -1020,3 +1011,4 @@ deployment.apps "dev-my-nginx" deleted
 * [Kubectl 문서](https://kubectl.docs.kubernetes.io)
 * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+

content/ko/docs/tasks/network/validate-dual-stack.md

@@ -39,7 +39,7 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
 ```
 ```
 10.244.1.0/24
-a00:100::/24
+2001:db8::/64
 ```
 단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다.
 
@@ -50,8 +50,8 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
 ```
 ```
 Hostname: k8s-linuxpool1-34450317-0
-InternalIP: 10.240.0.5
+InternalIP: 10.0.0.5
-InternalIP: 2001:1234:5678:9abc::5
+InternalIP: 2001:db8:10::5
 ```
 
 ### 파드 어드레싱 검증
@@ -63,7 +63,7 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin
 ```
 ```
 10.244.1.4
-a00:100::4
+2001:db8::4
 ```
 
 `status.podIPs` fieldPath를 통한 다운워드(downward) API로 파드 IP들을 검증할 수도 있다. 다음 스니펫은 컨테이너 내 `MY_POD_IPS` 라는 환경 변수를 통해 파드 IP들을 어떻게 노출시킬 수 있는지 보여준다.
@@ -82,7 +82,7 @@ a00:100::4
 kubectl exec -it pod01 -- set | grep MY_POD_IPS
 ```
 ```
-MY_POD_IPS=10.244.1.4,a00:100::4
+MY_POD_IPS=10.244.1.4,2001:db8::4
 ```
 
 파드의 IP 주소는 또한 컨테이너 내 `/etc/hosts` 에 적힐 것이다. 다음 커맨드는 이중 스택 파드의 `/etc/hosts` 에 cat을 실행시킨다. 출력 값을 통해 파드의 IPv4 및 IPv6 주소 모두 검증할 수 있다.
@@ -99,7 +99,7 @@ fe00::0    ip6-mcastprefix
 fe00::1    ip6-allnodes
 fe00::2    ip6-allrouters
 10.244.1.4    pod01
-a00:100::4    pod01
+2001:db8::4    pod01
 ```
 
 ## 서비스 검증
@@ -161,9 +161,9 @@ metadata:
     app.kubernetes.io/name: MyApp
   name: my-service
 spec:
-  clusterIP: fd00::5118
+  clusterIP: 2001:db8:fd00::5118
   clusterIPs:
-  - fd00::5118
+  - 2001:db8:fd00::5118
   ipFamilies:
   - IPv6
   ipFamilyPolicy: SingleStack
@@ -210,7 +210,7 @@ Type:              ClusterIP
 IP Family Policy:  PreferDualStack
 IP Families:       IPv4,IPv6
 IP:                10.0.216.242
-IPs:               10.0.216.242,fd00::af55
+IPs:               10.0.216.242,2001:db8:fd00::af55
 Port:              <unset>  80/TCP
 TargetPort:        9376/TCP
 Endpoints:         <none>
@@ -233,6 +233,8 @@ kubectl get svc -l app.kubernetes.io/name: MyApp
 서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
 
 ```shell
-NAME         TYPE           CLUSTER-IP   EXTERNAL-IP        PORT(S)        AGE
+NAME         TYPE           CLUSTER-IP            EXTERNAL-IP        PORT(S)        AGE
-my-service   LoadBalancer   fd00::7ebc   2603:1030:805::5   80:30790/TCP   35s
+my-service   LoadBalancer   2001:db8:fd00::7ebc   2603:1030:805::5   80:30790/TCP   35s
 ```
+
+

content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -54,31 +54,8 @@ Metrics Server를 실행하는 방법을 보려면
 
 ## php-apache 서버 구동 및 노출
 
-HorizontalPodAutoscaler 예시에서, 
+HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하여 컨테이너를 실행하는 디플로이먼트를 시작하고,
-먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. 
+다음의 매니페스트를 사용하여 디플로이먼트를
-`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다.
-
-```dockerfile
-FROM php:5-apache
-COPY index.php /var/www/html/index.php
-RUN chmod a+rx index.php
-```
-
-아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며,
-이를 이용해 클러스터에 부하를 시뮬레이트한다.
-
-```php
-<?php
-  $x = 0.0001;
-  for ($i = 0; $i <= 1000000; $i++) {
-    $x += sqrt($x);
-  }
-  echo "OK!";
-?>
-```
-
-컨테이너 이미지를 만들었다면, 
-방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 
 {{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다.
 
 {{< codenew file="application/php-apache.yaml" >}}

content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md

@@ -362,3 +362,4 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
 활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와 
 `--cluster-signing-key-file` 매개 변수를 
 컨트롤러 관리자에 전달한다.
+

content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md

@@ -31,12 +31,12 @@ source /usr/share/bash-completion/bash_completion
 이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
 
 {{< tabs name="kubectl_bash_autocompletion" >}}
-{{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
+{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
 echo 'source <(kubectl completion bash)' >>~/.bashrc
 {{< /tab >}}
 {{< tab name="시스템 전체에 적용" codelang="bash" >}}
 kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
-{{< /tab >}}}
+{{< /tab >}}
 {{< /tabs >}}
 
 kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
@@ -51,3 +51,7 @@ bash-completion은 `/etc/bash_completion.d` 에 있는 모든 자동 완성 스
 {{< /note >}}
 
 두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
+셸의 현재 세션에서 bash 자동 완성을 활성화하려면 `exec bash`를 실행한다.
+```bash
+exec bash
+```

content/ko/docs/tutorials/hello-minikube.md

@@ -94,7 +94,7 @@ minikube dashboard --url
 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
 
     ```shell
-    kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
+    kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
     ```
 
 2. 디플로이먼트 보기
@@ -155,7 +155,7 @@ minikube dashboard --url
     `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
     원한다는 뜻이다.
 
-    `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
+    `registry.k8s.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
     사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
 
 2. 생성한 서비스 살펴보기
@@ -303,3 +303,4 @@ minikube delete
 * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
 * [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
 * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
+

content/ko/docs/tutorials/security/apparmor.md

@@ -6,8 +6,6 @@ content_type: tutorial
 weight: 10
 ---
 
-
-
 <!-- overview -->
 
 {{< feature-state for_k8s_version="v1.4" state="beta" >}}
@@ -108,7 +106,7 @@ AppArmor 지원이 포함된 Kubelet (>= v1.4)이면
 노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다.
 
 ```shell
-kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
+kubectl get nodes -o=jsonpath='{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}{"\n"}{end}'
 ```
 ```
 gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
@@ -120,10 +118,10 @@ gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor e
 
 <!-- lessoncontent -->
 
-## 파드 보안 강화하기 {#securing-a-pod}
+## 파드 보안 강화하기
 
 {{< note >}}
-AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
+AppArmor는 현재 베타이며, 이 때문에 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
 어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은
 [일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고)
 {{< /note >}}
@@ -166,7 +164,7 @@ kubectl exec <pod_name> cat /proc/1/attr/current
 k8s-apparmor-example-deny-write (enforce)
 ```
 
-## 예시 {#example}
+## 예시
 
 *이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.*
 
@@ -327,9 +325,9 @@ Events:
 파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile
 "k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다.
 
-## 관리 {#administration}
+## 관리
 
-### 프로파일과 함께 노드 설정하기 {#setting-up-nodes-with-profiles}
+### 프로파일과 함께 노드 설정하기
 
 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다.
 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다.
@@ -348,36 +346,9 @@ Events:
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
 
-### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
+### AppArmor 비활성화
 
-{{< note >}}
+클러스터에서 AppArmor를 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
-파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. 
-더 자세한 내용은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/) 문서를 참고한다.
-{{< /note >}}
-
-만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
-파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
-
-```
---enable-admission-plugins=PodSecurityPolicy[,others...]
-```
-
-AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
-
-```yaml
-apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
-apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
-```
-
-기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에
-컨테이너에 기본으로 적용하는 프로파일을 지정한다.
-허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다.
-두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다.
-프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 [API 참조](#api-reference)를 찾아본다.
-
-### AppArmor 비활성화 {#disabling-apparmor}
-
-클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
 
 ```
 --feature-gates=AppArmor=false
@@ -392,7 +363,7 @@ AppArmor가 general availability (GA) 상태로 바뀌면
 AppArmor 기능을 비활성화하는 옵션은 제거될 것이다.
 {{</note>}}
 
-## 프로파일 제작 {#authoring-profiles}
+## 프로파일 제작
 
 AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다.
 다행히 이 작업에 도움 되는 도구가 있다.
@@ -409,9 +380,9 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 [AppArmor 실패](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)에서 제공한다.
 
 
-## API 참조 {#api-reference}
+## API 참조
 
-### 파드 어노테이션 {#pod-annotation}
+### 파드 어노테이션
 
 컨테이너를 실행할 프로파일을 지정한다.
 
@@ -420,7 +391,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
   분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다.
 - **값**: 아래 기술된 프로파일 참조
 
-### 프로파일 참조 {#profile-reference}
+### 프로파일 참조
 
 - `runtime/default`: 기본 런타임 프로파일을 참조한다.
   - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
@@ -434,22 +405,6 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 
 다른 어떤 프로파일 참조 형식도 유효하지 않다.
 
-### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
-
-아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기
-
-* **키**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
-* **값**: 프로파일 참조. 위에 기술됨.
-
-파드 컨테이너에서 지정을 허용하는 프로파일 목록 지정하기
-
-* **키**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
-* **값**: 컴마로 구분된 참조 프로파일 목록(위에 기술함)
-  - 비록 이스케이프된 쉼표(%2C ',')도 프로파일 이름에서 유효한 문자이지만
-    여기에서 명시적으로 허용하지 않는다.
-
-
-
 ## {{% heading "whatsnext" %}}
 
 

content/ko/docs/tutorials/services/source-ip.md

@@ -48,7 +48,7 @@ min-kubernetes-server-version: v1.5
 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.
 
 ```shell
-kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
+kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.4
 ```
 출력은 다음과 같다.
 ```
@@ -323,10 +323,10 @@ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
 ```
 
 `service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
-모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
+모든 노드의 포트를 가리킨다. 이것을 테스트할 수 있다.
 
 ```shell
-kubectl get pod -o wide -l run=source-ip-app
+kubectl get pod -o wide -l app=source-ip-app
 ```
 출력은 다음과 유사하다.
 ```

content/ko/docs/tutorials/stateful-application/basic-stateful-set.md

@@ -127,8 +127,9 @@ web-1     0/1       ContainerCreating   0         0s
 web-1     1/1       Running   0         18s
 ```
 
-참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
+참고로 `web-1` 파드는 `web-0` 파드가
-및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
+_Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
+및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에는 시작되지 않음에 주의한다.
 
 ## 스테이트풀셋 안에 파드
 
@@ -214,6 +215,8 @@ kubectl get pod -w -l app=nginx
 
 ```shell
 kubectl delete pod -l app=nginx
+```
+```
 pod "web-0" deleted
 pod "web-1" deleted
 ```
@@ -334,8 +337,9 @@ web-1
 
 {{< note >}}
 위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면
-다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
+다음을 실행하여 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다
-([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함).
+([hostPath 볼륨을 사용할 때의 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 
+인함).
 
 `for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done`
 
@@ -521,7 +525,8 @@ www-web-4   Bound     pvc-e11bb5f8-b508-11e6-932f-42010a800002   1Gi        RWO
 
 ### 롤링 업데이트
 
-`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다.
+`RollingUpdate` 업데이트 전략은 스테이트풀셋의 보장사항을 유지하면서
+스테이트풀셋 내의 모든 파드를 역순으로 업데이트한다.
 
 스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자.
 
@@ -601,9 +606,9 @@ web-0     1/1       Running   0         10s
 for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
 ```
 ```
-k8s.gcr.io/nginx-slim:0.8
+registry.k8s.io/nginx-slim:0.8
-k8s.gcr.io/nginx-slim:0.8
+registry.k8s.io/nginx-slim:0.8
-k8s.gcr.io/nginx-slim:0.8
+registry.k8s.io/nginx-slim:0.8
 
 ```
 
@@ -630,10 +635,10 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda
 statefulset.apps/web patched
 ```
 
-컨테이너의 이미지를 바꾸도록 스테이트풀셋을 또 패치하자.
+컨테이너의 이미지를 바꾸도록 스테이트풀셋을 다시 패치한다.
 
 ```shell
-kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
+kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.7"}]'
 ```
 ```
 statefulset.apps/web patched
@@ -667,7 +672,7 @@ web-2     1/1       Running   0         18s
 kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
 ```
 ```
-k8s.gcr.io/nginx-slim:0.8
+registry.k8s.io/nginx-slim:0.8
 ```
 
 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은
@@ -708,7 +713,7 @@ web-2     1/1       Running   0         18s
 kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
 ```
 ```
-k8s.gcr.io/nginx-slim:0.7
+registry.k8s.io/nginx-slim:0.7
 
 ```
 
@@ -751,13 +756,14 @@ web-1     1/1       Running   0         18s
 kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
 ```
 ```
-k8s.gcr.io/nginx-slim:0.8
+registry.k8s.io/nginx-slim:0.8
 ```
 
 `web-1` 는 원래 환경설정으로 복원되었는데
 이는 파드의 순번이 partition보다 작기 때문이다.
-스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을
+스테이트풀셋의 `.spec.template`이 갱신되면,
-가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나
+지정된 partition 이상의 순번을 가진 모든 파드는 업데이트된다.
+미만의 순번을 가진 파드라면 삭제되거나
 종료되어 원래 환경설정으로 복원된다.
 
 #### 단계적 롤아웃
@@ -807,10 +813,9 @@ web-0     1/1       Running   0         3s
 for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
 ```
 ```
-k8s.gcr.io/nginx-slim:0.7
+registry.k8s.io/nginx-slim:0.7
-k8s.gcr.io/nginx-slim:0.7
+registry.k8s.io/nginx-slim:0.7
-k8s.gcr.io/nginx-slim:0.7
+registry.k8s.io/nginx-slim:0.7
-
 ```
 
 `partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서
@@ -819,10 +824,12 @@ k8s.gcr.io/nginx-slim:0.7
 ### 삭제 시 동작
 
 `OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로,
-이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의
+이 업데이트 전략을 선택하면,
+스테이트풀셋 컨트롤러는 스테이트풀셋의
 `.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다.
 이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다.
 
+
 ## 스테이트풀셋 삭제하기
 
 스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다.

content/ko/examples/admin/konnectivity/konnectivity-server.yaml

@@ -8,7 +8,7 @@ spec:
   hostNetwork: true
   containers:
   - name: konnectivity-server-container
-    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16
+    image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32
     command: ["/proxy-server"]
     args: [
             "--logtostderr=true",

content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml

@@ -22,7 +22,7 @@ spec:
     - name: varlog
       mountPath: /var/log
   - name: count-agent
-    image: k8s.gcr.io/fluentd-gcp:1.30
+    image: registry.k8s.io/fluentd-gcp:1.30
     env:
     - name: FLUENTD_ARGS
       value: -c /etc/fluentd-config/fluentd.conf

content/ko/examples/admin/sched/pod1.yaml

@@ -7,4 +7,4 @@ metadata:
 spec:
   containers:
   - name: pod-with-no-annotation-container
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/admin/sched/pod2.yaml

@@ -8,4 +8,4 @@ spec:
   schedulerName: default-scheduler
   containers:
   - name: pod-with-default-annotation-container
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/admin/sched/pod3.yaml

@@ -8,4 +8,4 @@ spec:
   schedulerName: my-scheduler
   containers:
   - name: pod-with-second-annotation-container
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/application/php-apache.yaml

@@ -14,7 +14,7 @@ spec:
     spec:
       containers:
       - name: php-apache
-        image: k8s.gcr.io/hpa-example
+        image: registry.k8s.io/hpa-example
         ports:
         - containerPort: 80
         resources:
@@ -22,9 +22,7 @@ spec:
             cpu: 500m
           requests:
             cpu: 200m
-
 ---
-
 apiVersion: v1
 kind: Service
 metadata:
@@ -36,4 +34,3 @@ spec:
   - port: 80
   selector:
     run: php-apache
-

content/ko/examples/application/web/web-parallel.yaml

@@ -30,7 +30,7 @@ spec:
     spec:
       containers:
       - name: nginx
-        image: k8s.gcr.io/nginx-slim:0.8
+        image: registry.k8s.io/nginx-slim:0.8
         ports:
         - containerPort: 80
           name: web

content/ko/examples/application/web/web.yaml

@@ -29,7 +29,7 @@ spec:
     spec:
       containers:
       - name: nginx
-        image: k8s.gcr.io/nginx-slim:0.8
+        image: registry.k8s.io/nginx-slim:0.8
         ports:
         - containerPort: 80
           name: web

content/ko/examples/application/zookeeper/zookeeper.yaml

@@ -68,7 +68,7 @@ spec:
       containers:
       - name: kubernetes-zookeeper
         imagePullPolicy: Always
-        image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
+        image: "registry.k8s.io/kubernetes-zookeeper:1.0-3.4.10"
         resources:
           requests:
             memory: "1Gi"

content/ko/examples/debug/node-problem-detector-configmap.yaml

@@ -23,7 +23,7 @@ spec:
       hostNetwork: true
       containers:
       - name: node-problem-detector
-        image: k8s.gcr.io/node-problem-detector:v0.1
+        image: registry.k8s.io/node-problem-detector:v0.1
         securityContext:
           privileged: true
         resources:

content/ko/examples/debug/node-problem-detector.yaml

@@ -23,7 +23,7 @@ spec:
       hostNetwork: true
       containers:
       - name: node-problem-detector
-        image: k8s.gcr.io/node-problem-detector:v0.1
+        image: registry.k8s.io/node-problem-detector:v0.1
         securityContext:
           privileged: true
         resources:

content/ko/examples/pods/inject/dapi-envars-container.yaml

@@ -5,7 +5,7 @@ metadata:
 spec:
   containers:
     - name: test-container
-      image: k8s.gcr.io/busybox:1.24
+      image: registry.k8s.io/busybox:1.24
       command: [ "sh", "-c"]
       args:
       - while true; do

content/ko/examples/pods/inject/dapi-envars-pod.yaml

@@ -5,7 +5,7 @@ metadata:
 spec:
   containers:
     - name: test-container
-      image: k8s.gcr.io/busybox
+      image: registry.k8s.io/busybox
       command: [ "sh", "-c"]
       args:
       - while true; do

content/ko/examples/pods/inject/dapi-volume-resources.yaml

@@ -5,7 +5,7 @@ metadata:
 spec:
   containers:
     - name: client-container
-      image: k8s.gcr.io/busybox:1.24
+      image: registry.k8s.io/busybox:1.24
       command: ["sh", "-c"]
       args:
       - while true; do

content/ko/examples/pods/inject/dapi-volume.yaml

@@ -12,7 +12,7 @@ metadata:
 spec:
   containers:
     - name: client-container
-      image: k8s.gcr.io/busybox
+      image: registry.k8s.io/busybox
       command: ["sh", "-c"]
       args:
       - while true; do

content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml

@@ -29,4 +29,4 @@ spec:
             - key-2
   containers:
   - name: with-node-affinity
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/pods/pod-with-node-affinity.yaml

@@ -23,4 +23,4 @@ spec:
             - another-node-label-value
   containers:
   - name: with-node-affinity
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/pods/pod-with-pod-affinity.yaml

@@ -26,4 +26,4 @@ spec:
           topologyKey: topology.kubernetes.io/zone
   containers:
   - name: with-pod-affinity
-    image: k8s.gcr.io/pause:2.0
+    image: registry.k8s.io/pause:2.0

content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml

@@ -23,4 +23,4 @@ spec:
             - zoneC
   containers:
   - name: pause
-    image: k8s.gcr.io/pause:3.1
+    image: registry.k8s.io/pause:3.1

content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml

@@ -14,4 +14,4 @@ spec:
         foo: bar
   containers:
   - name: pause
-    image: k8s.gcr.io/pause:3.1
+    image: registry.k8s.io/pause:3.1

content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml

@@ -20,4 +20,4 @@ spec:
         foo: bar
   containers:
   - name: pause
-    image: k8s.gcr.io/pause:3.1
+    image: registry.k8s.io/pause:3.1

content/ko/releases/version-skew-policy.md

@@ -1,11 +1,11 @@
 ---
-
+# reviewers:
-
+# - sig-api-machinery
-
+# - sig-architecture
-
+# - sig-cli
-
+# - sig-cluster-lifecycle
-
+# - sig-node
-
+# - sig-release
 title: 버전 차이(skew) 정책
 type: docs
 description: >
@@ -23,7 +23,7 @@ description: >
 쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다.
 자세한 내용은 [쿠버네티스 릴리스 버전](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning)을 참조한다.
 
-쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
+쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 [1년간의 패치 지원](/releases/patch-releases/#support-period)을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
 
 보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다.
 패치 릴리스는 각 브랜치별로 [정기적인 주기](/releases/patch-releases/#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.