diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md index e48b08b8a3..3743e9b267 100644 --- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -9,12 +9,9 @@ weight: 10 -쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다. -이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다. -이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다. - -시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다. -이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](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" >}} - - ## 크론잡(CronJob) 생성 {#creating-a-cron-job} @@ -96,8 +88,7 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 50s 75s ``` -크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지 -`LAST SCHEDULE`에서 확인해야 한다. +크론 잡 `hello` 가 `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`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다. -* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다. +* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. + 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다. +* `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` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다. diff --git a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md b/content/ko/docs/tasks/job/indexed-parallel-processing-static.md index 512b11758e..f193d23fc9 100644 --- a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md +++ b/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` 환경변수에 인덱스를 노출할 수 있도록 한다. diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 7ae472280e..b1d818ed42 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/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` 업데이트 전략으로 데몬셋 생성 diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index fe0263c538..1a98164bd1 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -6,8 +6,6 @@ title: GPU 스케줄링 description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다. --- - - {{< 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 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 224dd63902..896f042c03 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -86,20 +86,12 @@ metadata: name: example-configmap-1-8mbdf7882g ``` -env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다. - -{{< note >}} -로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다. -{{< /note >}} - -다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다. +env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다. ```shell # .env 파일 생성 -# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다 cat <.env FOO=Bar -BAZ EOF cat <./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" >}}/) + diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 47126cd4f4..9246f79ecb 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/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: 2001:1234:5678:9abc::5 +InternalIP: 10.0.0.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: 80/TCP TargetPort: 9376/TCP Endpoints: @@ -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 -my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s ``` + + diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index da1f9dc6a6..1b6ae0f36a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -54,31 +54,8 @@ Metrics Server를 실행하는 방법을 보려면 ## php-apache 서버 구동 및 노출 -HorizontalPodAutoscaler 예시에서, -먼저 도커 허브의 `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 - -``` - -컨테이너 이미지를 만들었다면, -방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 +HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하여 컨테이너를 실행하는 디플로이먼트를 시작하고, +다음의 매니페스트를 사용하여 디플로이먼트를 {{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다. {{< codenew file="application/php-apache.yaml" >}} diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md index 0839ad9587..e932a2c4dc 100644 --- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/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` 매개 변수를 컨트롤러 관리자에 전달한다. + diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index cf1096aeb6..33ce4a7afa 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/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 +``` diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index ce93967a59..fc360d1d06 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/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/)에 대해서 더 배워 본다. + diff --git a/content/ko/docs/tutorials/security/apparmor.md b/content/ko/docs/tutorials/security/apparmor.md index c454fef915..f8eff05b43 100644 --- a/content/ko/docs/tutorials/security/apparmor.md +++ b/content/ko/docs/tutorials/security/apparmor.md @@ -6,8 +6,6 @@ content_type: tutorial weight: 10 --- - - {{< 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 -## 파드 보안 강화하기 {#securing-a-pod} +## 파드 보안 강화하기 {{< note >}} -AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면, +AppArmor는 현재 베타이며, 이 때문에 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면, 어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은 [일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고) {{< /note >}} @@ -166,7 +164,7 @@ kubectl exec 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 >}} -파드시큐리티폴리시는 쿠버네티스 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: -apparmor.security.beta.kubernetes.io/allowedProfileNames: [,others...] -``` - -기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에 -컨테이너에 기본으로 적용하는 프로파일을 지정한다. -허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다. -두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다. -프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 [API 참조](#api-reference)를 찾아본다. - -### AppArmor 비활성화 {#disabling-apparmor} - -클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다. +클러스터에서 AppArmor를 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다. ``` --feature-gates=AppArmor=false @@ -392,7 +363,7 @@ AppArmor가 general availability (GA) 상태로 바뀌면 AppArmor 기능을 비활성화하는 옵션은 제거될 것이다. {{}} -## 프로파일 제작 {#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" %}} diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 227e981e4b..7617e33685 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/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 ``` 출력은 다음과 유사하다. ``` diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 2ce20300af..b961580a73 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/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/#파드의-단계) 참고) -및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 +_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`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 -([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). +다음을 실행하여 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +([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 -k8s.gcr.io/nginx-slim:0.8 -k8s.gcr.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 +registry.k8s.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 -k8s.gcr.io/nginx-slim:0.7 -k8s.gcr.io/nginx-slim:0.7 - +registry.k8s.io/nginx-slim:0.7 +registry.k8s.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) 삭제를 둘 다 지원한다. diff --git a/content/ko/examples/admin/konnectivity/konnectivity-server.yaml b/content/ko/examples/admin/konnectivity/konnectivity-server.yaml index 8d8ef56195..0f2fe702a0 100644 --- a/content/ko/examples/admin/konnectivity/konnectivity-server.yaml +++ b/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", diff --git a/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml index ddfb8104cb..a621a9fb2a 100644 --- a/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml +++ b/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 diff --git a/content/ko/examples/admin/sched/pod1.yaml b/content/ko/examples/admin/sched/pod1.yaml index 560b6aa0fb..7183dd62c0 100644 --- a/content/ko/examples/admin/sched/pod1.yaml +++ b/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 \ No newline at end of file + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/ko/examples/admin/sched/pod2.yaml b/content/ko/examples/admin/sched/pod2.yaml index 2f065efe65..b78ab64a4b 100644 --- a/content/ko/examples/admin/sched/pod2.yaml +++ b/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 diff --git a/content/ko/examples/admin/sched/pod3.yaml b/content/ko/examples/admin/sched/pod3.yaml index a1b8db3200..6614143829 100644 --- a/content/ko/examples/admin/sched/pod3.yaml +++ b/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 diff --git a/content/ko/examples/application/php-apache.yaml b/content/ko/examples/application/php-apache.yaml index 5eb04cfb89..d29d2b9159 100644 --- a/content/ko/examples/application/php-apache.yaml +++ b/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 - diff --git a/content/ko/examples/application/web/web-parallel.yaml b/content/ko/examples/application/web/web-parallel.yaml index 4eab2dc206..a6633f476c 100644 --- a/content/ko/examples/application/web/web-parallel.yaml +++ b/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 diff --git a/content/ko/examples/application/web/web.yaml b/content/ko/examples/application/web/web.yaml index 37c1fabf9c..95244cd72b 100644 --- a/content/ko/examples/application/web/web.yaml +++ b/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 diff --git a/content/ko/examples/application/zookeeper/zookeeper.yaml b/content/ko/examples/application/zookeeper/zookeeper.yaml index 4d893b369b..0f3f6cf9d1 100644 --- a/content/ko/examples/application/zookeeper/zookeeper.yaml +++ b/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" diff --git a/content/ko/examples/debug/node-problem-detector-configmap.yaml b/content/ko/examples/debug/node-problem-detector-configmap.yaml index 168714f753..cbdc783414 100644 --- a/content/ko/examples/debug/node-problem-detector-configmap.yaml +++ b/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: diff --git a/content/ko/examples/debug/node-problem-detector.yaml b/content/ko/examples/debug/node-problem-detector.yaml index 6ffa19bcc3..f106c327ef 100644 --- a/content/ko/examples/debug/node-problem-detector.yaml +++ b/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: diff --git a/content/ko/examples/pods/inject/dapi-envars-container.yaml b/content/ko/examples/pods/inject/dapi-envars-container.yaml index 55bd4dd263..4267053a06 100644 --- a/content/ko/examples/pods/inject/dapi-envars-container.yaml +++ b/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 diff --git a/content/ko/examples/pods/inject/dapi-envars-pod.yaml b/content/ko/examples/pods/inject/dapi-envars-pod.yaml index 071fa82bb3..d5a646e087 100644 --- a/content/ko/examples/pods/inject/dapi-envars-pod.yaml +++ b/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 diff --git a/content/ko/examples/pods/inject/dapi-volume-resources.yaml b/content/ko/examples/pods/inject/dapi-volume-resources.yaml index ecb231e0cf..5b52bf8448 100644 --- a/content/ko/examples/pods/inject/dapi-volume-resources.yaml +++ b/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 diff --git a/content/ko/examples/pods/inject/dapi-volume.yaml b/content/ko/examples/pods/inject/dapi-volume.yaml index 0f0a9f2e5c..682098d27f 100644 --- a/content/ko/examples/pods/inject/dapi-volume.yaml +++ b/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 diff --git a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml index 10d3056f2d..cb8c5650b0 100644 --- a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/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 diff --git a/content/ko/examples/pods/pod-with-node-affinity.yaml b/content/ko/examples/pods/pod-with-node-affinity.yaml index ebc6f14490..5fedc554bf 100644 --- a/content/ko/examples/pods/pod-with-node-affinity.yaml +++ b/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 \ No newline at end of file + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/ko/examples/pods/pod-with-pod-affinity.yaml b/content/ko/examples/pods/pod-with-pod-affinity.yaml index 6d075e0860..1a4fd74fd7 100644 --- a/content/ko/examples/pods/pod-with-pod-affinity.yaml +++ b/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 diff --git a/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml index 98823f9d86..12b117a814 100644 --- a/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml +++ b/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 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml index a0a41188ec..02d2c6ca40 100644 --- a/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml +++ b/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 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml index aa142b7abb..c111195155 100644 --- a/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml +++ b/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 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/releases/version-skew-policy.md b/content/ko/releases/version-skew-policy.md index 7640bd1859..af0594e3d8 100644 --- a/content/ko/releases/version-skew-policy.md +++ b/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)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.