Merge pull request #35115 from bconfiden2/220716_Update_outdated_dev-1.24-ko.2_M65-M70

[ko] Update outdated files in dev-1.24-ko.2 (M65-M70)

content/ko/docs/setup/_index.md

@@ -27,6 +27,13 @@ card:
 [쿠버네티스를 다운로드](/releases/download/)하여 
 로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.
 
+`kube-apiserver`나 `kube-proxy`와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은
+클러스터 내에서 [컨테이너 이미지](/releases/download/#container-images)를 통해 배포할 수 있다.
+
+쿠버네티스 컴포넌트들은 가급적 컨테이너 이미지로 실행하는 것을 **추천**하며,
+이를 통해 쿠버네티스가 해당 컴포넌트들을 관리하도록 한다.
+컨테이너를 구동하는 컴포넌트(특히 kubelet)는 여기에 속하지 않는다.
+
 쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 
 같은 매니지드 서비스를 선택할 수도 있다.
 광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 
@@ -60,4 +67,5 @@ card:
 쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 
 리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 
 다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
-- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.
+
+- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/concepts/windows/)를 살펴본다.

content/ko/docs/setup/best-practices/certificates.md

@@ -23,7 +23,7 @@ weight: 40
 
 * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
 * API 서버가 kubelet과 통신하기 위한 
-  kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
+  kubelet [서버 인증서](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)
 * API 서버 엔드포인트를 위한 서버 인증서
 * API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
 * API 서버에서 kubelet과 통신을 위한 클라이언트 인증서

content/ko/docs/setup/production-environment/_index.md

@@ -178,9 +178,6 @@ etcd 백업 계획을 세우려면
   머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 
   또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. 
   이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다.
-- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를 
-실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. 
-[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다.
 - *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼 
   확장하는 것에 대한 계획이 있어야 한다. 
   실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 
@@ -221,16 +218,28 @@ apiserver는 또한 플러그인을 사용하여
   LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다.
   쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 
   [인증](/docs/reference/access-authn-authz/authentication/)을 참조한다.
-- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다.
+- *인가*: 일반 사용자 인가를 위해,
-  - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다.
+  RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서
-  - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
+  사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를
+  확인할 수 있다.
+  - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 
+    특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다.
+    특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다.
+    그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을
+    특정 사용자에게 연결할 수 있다.
+  - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의
+    리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다.
+    정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류),
+    그리고 '대상(사용자 또는 그룹)', '리소스 속성',
+    '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다.
+    자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
 
 프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다.
 
-- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, 
+- *인가 모드 설정*: 쿠버네티스 API 서버
+  ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, 
   *`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다.
-예를 들어, (*`/etc/kubernetes/manifests`*에 있는) 
+  예를 들어, *`kube-adminserver.yaml`* 파일(*`/etc/kubernetes/manifests`*에 있는) 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. 
-*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. 
   이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
 - *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우, 
   사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. 
@@ -268,8 +277,12 @@ DNS 서비스도 확장할 준비가 되어 있어야 한다.
   기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다.
   [서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 
   새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
-  - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다.
+  - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다.
-  - 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다.
+    [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서
+    예시를 확인한다.
+  - 서비스 어카운트에 RBAC 권한을 할당한다.
+    [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서
+    상세 사항을 확인한다.
 
 ## {{% heading "whatsnext" %}}
 
@@ -282,7 +295,9 @@ DNS 서비스도 확장할 준비가 되어 있어야 한다.
   [API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) 
   등의 기능에 대한 고가용성을 
   어떻게 보장할지를 계획한다.
-- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 
+- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/),
+  [kops](/ko/docs/setup/production-environment/tools/kops/),
+  [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 
   하나를 선택한다.
 - [인증](/docs/reference/access-authn-authz/authentication/) 및 
   [인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -36,7 +36,7 @@ _dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접
 더 이상 쿠버네티스에 포함되지 않는다(이 제거는 
 v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). 
 이 제거가 어떻게 영향을 미치는지 알아보려면 
-[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. 
+[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. 
 dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, 
 [dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
 
@@ -46,6 +46,41 @@ v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고
 
 
 <!-- body -->
+## 필수 요소들 설치 및 구성하기
+
+다음 단계에서는 리눅스의 쿠버네티스 노드를 위한 일반적인 설정들을 적용한다.
+
+만약 필요하지 않다고 생각한다면 몇몇 설정들은 넘어가도 무방하다.
+
+더 자세한 정보는, [네트워크 플러그인 요구사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)이나 각자 사용 중인 컨테이너 런타임에 해당하는 문서를 확인한다.
+
+### IPv4를 포워딩하여 iptables가 브리지된 트래픽을 보게 하기
+
+`lsmod | grep br_netfilter`를 실행하여 `br_netfilter` 모듈이 로드되었는지 확인한다.
+
+명시적으로 로드하려면, `sudo modprobe br_netfilter`를 실행한다.
+
+리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables`가 1로 설정되어 있는지 확인한다. 예를 들어,
+
+```bash
+cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
+overlay
+br_netfilter
+EOF
+
+sudo modprobe overlay
+sudo modprobe br_netfilter
+
+# 필요한 sysctl 파라미터를 설정하면, 재부팅 후에도 값이 유지된다.
+cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
+net.bridge.bridge-nf-call-iptables  = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+net.ipv4.ip_forward                 = 1
+EOF
+
+# 재부팅하지 않고 sysctl 파라미터 적용하기
+sudo sysctl --system
+```
 
 ## cgroup 드라이버
 
@@ -132,45 +167,22 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
 
 {{% thirdparty-content %}}
 
-
 ### containerd
 
 이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다.
 
 다음 명령을 사용하여 시스템에 containerd를 설치한다.
 
-1. 필수 구성 요소를 설치 및 구성한다.
+[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)의 지침에 따라, 유효한 환경 설정 파일(`config.toml`)을 생성한다.
 
-   (이 지침은 리눅스 노드에만 적용된다)
+{{< tabs name="Finding your config.toml file" >}}
-
+{{% tab name="Linux" %}}
-   ```shell
+`/etc/containerd/config.toml` 경로에서 파일을 찾을 수 있음.
-   cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
+{{% /tab %}}
-   overlay
+{{< tab name="Windows" >}}
-   br_netfilter
+`C:\Program Files\containerd\config.toml` 경로에서 파일을 찾을 수 있음.
-   EOF
+{{< /tab >}}
-
+{{< /tabs >}}
-   sudo modprobe overlay
-   sudo modprobe br_netfilter
-
-   # 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
-   cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
-   net.bridge.bridge-nf-call-iptables  = 1
-   net.ipv4.ip_forward                 = 1
-   net.bridge.bridge-nf-call-ip6tables = 1
-   EOF
-
-   # 재부팅하지 않고 sysctl 파라미터 적용
-   sudo sysctl --system
-   ```
-
-1. containerd를 설치한다.
-
-   [containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) 
-   문서를 확인하고, 
-   유효한 환경 설정 파일(`config.toml`)을 작성하는 부분까지의 
-   가이드를 따른다. 
-   리눅스에서, 이 파일은 `/etc/containerd/config.toml`에 존재한다. 
-   윈도우에서, 이 파일은 `C:\Program Files\containerd\config.toml`에 존재한다.
 
 리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다.
 윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다.
@@ -185,6 +197,14 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
     SystemdCgroup = true
 ```
+{{< note >}}
+만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면,
+CRI integration 플러그인은 기본적으로 비활성화되어 있다.
+
+쿠버네티스에서 containerd를 사용하기 위해서는 CRI support가 활성화되어 있어야 한다.
+`cri`가 `/etc/containerd/config.toml` 파일 안에 있는 `disabled_plugins` 목록에 포함되지 않도록 주의하자.
+만약 해당 파일을 변경하였다면, `containerd`를 다시 시작한다.
+{{< /note >}}
 
 이 변경 사항을 적용하려면, containerd를 재시작한다.
 
@@ -193,7 +213,19 @@ sudo systemctl restart containerd
 ```
 
 kubeadm을 사용하는 경우,
-[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다.
+[kubelet용 cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver)를 수동으로 구성한다.
+
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd}
+
+[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서
+아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
+
+```toml
+[plugins."io.containerd.grpc.v1.cri"]
+  sandbox_image = "k8s.gcr.io/pause:3.2"
+```
+
+설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다.
 
 ### CRI-O
 
@@ -221,6 +253,19 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
 
 CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-o}
+
+[CRI-O 설정](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md)에서
+아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
+
+```toml
+[crio.image]
+pause_image="registry.k8s.io/pause:3.6"
+```
+
+이 옵션은 `systemctl reload crio` 혹은 `crio` 프로세스에 `SIGHUP`을 보내 변경사항을 적용하기 위한
+live configuration reload 기능을 지원한다.
+
 ### 도커 엔진 {#docker}
 
 {{< note >}}
@@ -237,6 +282,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 
 `cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd}
+
+`cri-dockerd` 어댑터는, 
+파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
+해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
+
 ### 미란티스 컨테이너 런타임 {#mcr}
 
 [미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 
@@ -251,6 +302,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 CRI 소켓의 경로를 찾으려면 
 `cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr}
+
+`cri-dockerd` 어댑터는, 
+파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
+해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
+
 ## {{% heading "whatsnext" %}}
 
 컨테이너 런타임과 더불어, 클러스터에는 

content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md

@@ -45,26 +45,6 @@ card:
 네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는
 경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다.
 
-## iptables가 브리지된 트래픽을 보게 하기
-
-`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다.
-
-리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다.
-
-```bash
-cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
-br_netfilter
-EOF
-
-cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
-net.bridge.bridge-nf-call-ip6tables = 1
-net.bridge.bridge-nf-call-iptables = 1
-EOF
-sudo sysctl --system
-```
-
-자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
-
 ## 필수 포트 확인 {#check-required-ports}
 [필수 포트들](/ko/docs/reference/ports-and-protocols/)은
 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
@@ -74,7 +54,7 @@ sudo sysctl --system
 nc 127.0.0.1 6443
 ```
 
-사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
+사용자가 사용하는 파드 네트워크 플러그인은 특정 포트를 열어야 할 수도
 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
 플러그인 문서를 참고한다.
 
@@ -202,7 +182,6 @@ name=Kubernetes
 baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
 enabled=1
 gpgcheck=1
-repo_gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
 exclude=kubelet kubeadm kubectl
 EOF

content/ko/docs/setup/production-environment/tools/kubespray.md

@@ -6,7 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
+이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
 
 Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
 
@@ -46,7 +46,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은
 * 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
   * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
   * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
-  * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
+  * [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal)
 
 ### (2/5) 인벤토리 파일 구성하기
 
@@ -93,7 +93,8 @@ Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _sca
 
 ### 클러스터 스케일링하기
 
-scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
+scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자.
+remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
 
 ### 클러스터 업그레이드 하기