[ko] Update outdated files in dev-1.21-ko.6 (p3)

Author: jihoon-seo

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -50,7 +50,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
 URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml
 ```
 
 ```shell

content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -17,6 +17,11 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
 `kubeconfig`라는 이름의 파일이 있다는 의미는 아니다.
 {{< /note >}}
 
+{{< warning >}}
+신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. 
+신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다.
+{{< /warning>}}
+
 기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다.
 `KUBECONFIG` 환경 변수를 설정하거나
 [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서
@@ -154,4 +159,3 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
 
 
 
-

content/ko/docs/concepts/containers/images.md

@@ -77,6 +77,20 @@ weight: 10
 
 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
 
+### 이미지풀백오프(ImagePullBackOff)
+
+kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, 
+`ImagePullBackOff`로 인해 컨테이너가 
+[Waiting](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) 상태에 있을 수 있다.
+
+`ImagePullBackOff`라는 상태는 (이미지 이름이 잘못됨, 또는 `imagePullSecret` 없이 
+비공개 레지스트리에서 풀링 시도 등의 이유로) 쿠버네티스가 컨테이너 이미지를 
+가져올 수 없기 때문에 컨테이너를 실행할 수 없음을 의미한다. `BackOff`라는 단어는 
+쿠버네티스가 백오프 딜레이를 증가시키면서 이미지 풀링을 계속 시도할 것임을 나타낸다.
+
+쿠버네티스는 시간 간격을 늘려가면서 시도를 계속하며, 시간 간격의 상한은 쿠버네티스 코드에 
+300초(5분)로 정해져 있다.
+
 ## 이미지 인덱스가 있는 다중 아키텍처 이미지
 
 바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.

content/ko/docs/concepts/extend-kubernetes/operator.md

@@ -116,14 +116,15 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 * [Charmed Operator Framework](https://juju.is/)
 * [kubebuilder](https://book.kubebuilder.io/) 사용하기
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
-* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
+* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를
   사용하여 직접 구현하기
 * [오퍼레이터 프레임워크](https://operatorframework.io)
 * [shell-operator](https://github.com/flant/shell-operator)
 
 ## {{% heading "whatsnext" %}}
 
 
+* {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [오퍼레이터 백서](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md) 읽어보기
 * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기
 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기

content/ko/docs/concepts/policy/pod-security-policy.md

@@ -11,7 +11,8 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
 
-파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다.
+파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은
+[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
 
 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
 부여할 수 있다.
@@ -48,10 +49,9 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는
 
 ## 파드 시큐리티 폴리시 활성화
 
-파드 시큐리티 폴리시 제어는 선택 사항(하지만 권장함)인
-[어드미션
-컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로
-구현된다. [어드미션 컨트롤러 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면
+파드 시큐리티 폴리시 제어는 선택 사항인 [어드미션
+컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 구현된다. 
+[어드미션 컨트롤러를 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면
 파드시큐리티폴리시가 적용되지만,
 정책을 승인하지 않고 활성화하면 클러스터에
 **파드가 생성되지 않는다.**
@@ -110,11 +110,15 @@ roleRef:
   name: <role name>
   apiGroup: rbac.authorization.k8s.io
 subjects:
-# Authorize specific service accounts:
+# 네임스페이스의 모든 서비스 어카운트 승인(권장):
+- kind: Group
+  apiGroup: rbac.authorization.k8s.io
+  name: system:serviceaccounts:<authorized namespace>
+# 특정 서비스 어카운트 승인(권장하지 않음):
 - kind: ServiceAccount
   name: <authorized service account name>
   namespace: <authorized pod namespace>
-# Authorize specific users (not recommended):
+# 특정 사용자 승인(권장하지 않음):
 - kind: User
   apiGroup: rbac.authorization.k8s.io
   name: <authorized user name>
@@ -124,21 +128,55 @@ subjects:
 실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을
 부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다.
 ```yaml
-# Authorize all service accounts in a namespace:
+# 네임스페이스의 모든 서비스 어카운트 승인:
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: system:serviceaccounts
-# Or equivalently, all authenticated users in a namespace:
+# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: system:authenticated
 ```
 
 RBAC 바인딩에 대한 자세한 예는,
-[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고하길 바란다.
+[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고한다.
 파드시큐리티폴리시 인증에 대한 전체 예제는
-[아래](#예제)를 참고하길 바란다.
-
+[아래](#예제)를 참고한다.
+
+### 추천 예제
+
+파드시큐리티폴리시는 새롭고 간결해진 `PodSecurity` {{< glossary_tooltip
+text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다.
+이 변경에 대한 상세사항은 
+[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
+다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
+
+1. 파드시큐리티폴리시를 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
+    - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
+    - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
+    - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+
+2. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여 
+  파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.
+
+    ```yaml
+    apiVersion: rbac.authorization.k8s.io/v1
+    # 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다.
+    kind: ClusterRoleBinding
+    metadata:
+      name: psp-baseline-namespaces
+    roleRef:
+      kind: ClusterRole
+      name: psp-baseline
+      apiGroup: rbac.authorization.k8s.io
+    subjects:
+    - kind: Group
+      name: system:serviceaccounts:development
+      apiGroup: rbac.authorization.k8s.io
+    - kind: Group
+      name: system:serviceaccounts:canary
+      apiGroup: rbac.authorization.k8s.io
+    ```
 
 ### 문제 해결
 
@@ -661,5 +699,10 @@ spec:
 
 ## {{% heading "whatsnext" %}}
 
+- [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 
+미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서 
+파드시큐리티폴리시의 미래에 대해 알아본다.
+
 - 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
+
 - API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.

content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 테인트(Taints)와 톨러레이션(Tolerations)
 content_type: concept
 weight: 40
@@ -260,13 +264,27 @@ tolerations:
 
 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
 
-## 컨디션별 노드 테인트하기
+## 컨디션을 기준으로 노드 테인트하기
 
-노드 라이프사이클 컨트롤러는 `NoSchedule` 이펙트가 있는 노드 컨디션에 해당하는
-테인트를 자동으로 생성한다.
-마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다.
+컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
+[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
 
-쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
+스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. 
+이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
+예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 
+컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. 
+`MemoryPressure` 노드 조건이 활성화되면 
+컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다.
+
+새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. 
+또한 컨트롤 플레인은 `BestEffort` 이외의 
+{{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 
+`node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. 
+이는 쿠버네티스가 `Guaranteed` 또는 `Burstable` QoS 클래스를 갖는 파드(메모리 요청이 설정되지 않은 파드 포함)를 
+마치 그 파드들이 메모리 압박에 대처 가능한 것처럼 다루는 반면, 
+새로운 `BestEffort` 파드는 영향을 받는 노드에 할당하지 않기 때문이다.
+
+데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
 모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다.
 
   * `node.kubernetes.io/memory-pressure`
@@ -278,7 +296,6 @@ tolerations:
 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에
 임의의 톨러레이션을 추가할 수도 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
 * [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기

content/ko/docs/concepts/services-networking/dns-pod-service.md

@@ -50,7 +50,7 @@ options ndots:5
 ```
 
 요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는
-`data.prod.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
+`data.prod.svc.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
 
 ### DNS 레코드
 

content/ko/examples/policy/baseline-psp.yaml

@@ -0,0 +1,74 @@
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: baseline
+  annotations:
+    # 선택 사항: 기본 AppArmor 프로파일을 활성화한다. 이 경우 기본값을 설정해야 한다.
+    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
+    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
+    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
+spec:
+  privileged: false
+  # Moby의 기본 캐퍼빌리티 집합(NET_RAW는 제외되었음)
+  allowedCapabilities:
+    - 'CHOWN'
+    - 'DAC_OVERRIDE'
+    - 'FSETID'
+    - 'FOWNER'
+    - 'MKNOD'
+    - 'SETGID'
+    - 'SETUID'
+    - 'SETFCAP'
+    - 'SETPCAP'
+    - 'NET_BIND_SERVICE'
+    - 'SYS_CHROOT'
+    - 'KILL'
+    - 'AUDIT_WRITE'
+  # hostpath를 제외한 모든 볼륨 타입을 허용
+  volumes:
+    # '코어' 볼륨 타입
+    - 'configMap'
+    - 'emptyDir'
+    - 'projected'
+    - 'secret'
+    - 'downwardAPI'
+    # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)은 사용하기에 안전하다고 가정한다.
+    - 'csi'
+    - 'persistentVolumeClaim'
+    - 'ephemeral'
+    # hostpath 타입이 아닌 다른 모든 볼륨 타입을 허용
+    - 'awsElasticBlockStore'
+    - 'azureDisk'
+    - 'azureFile'
+    - 'cephFS'
+    - 'cinder'
+    - 'fc'
+    - 'flexVolume'
+    - 'flocker'
+    - 'gcePersistentDisk'
+    - 'gitRepo'
+    - 'glusterfs'
+    - 'iscsi'
+    - 'nfs'
+    - 'photonPersistentDisk'
+    - 'portworxVolume'
+    - 'quobyte'
+    - 'rbd'
+    - 'scaleIO'
+    - 'storageos'
+    - 'vsphereVolume'
+  hostNetwork: false
+  hostIPC: false
+  hostPID: false
+  readOnlyRootFilesystem: false
+  runAsUser:
+    rule: 'RunAsAny'
+  seLinux:
+    # 이 파드시큐리티폴리시는 노드가 SELinux가 아닌 AppArmor를 사용하고 있다고 가정한다.
+    # 파드시큐리티폴리시 SELinux API는 SELinux 파드 보안 표준을 표현할 수 없으므로,
+    # SELinux를 사용하는 경우 더 제한적인 기본값을 선택해야 한다.
+    rule: 'RunAsAny'
+  supplementalGroups:
+    rule: 'RunAsAny'
+  fsGroup:
+    rule: 'RunAsAny'