whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Third Korean l10n work for release 1.18

Browse Source 
- Translate cluster-administration/networking.md in Korean
- Fix issue with concepts/storage/volumes.md
- Translate /concepts/configuration/pod-overhead in Korean
- Update to Outdated files in the dev-1.18-ko.3 branch.
- Translate concepts/configuration/configmap.md in Korean
- Translate contribute/review/reviewing-prs/ in Korean
- Translate concepts/configuration/pod-priority-preemption.md in Korean
- Translate tasks/configure-pod-container/configure-volume-storage in Korean
- Translate contribute/new-content/new-content/ in Korean
- Translate concepts/architecture/control-plane-node-communication.md in Korean
- Restore the deleted master-node-communication.md file
- Translate concepts/cluster-administration/addons.md in Korean
- Translate contribute/new-content/overview/ in Korean
- Translate tasks/tools/install-kubectl.md in Korean
- Translate concepts/configuration/manage-resources-containers.md in Korean
- Translate tasks/administer-cluster/kubeadm/kubeadm-upgrade/ in Korean
- add new words to Korean glossary and fix minor
- Translate contribute/style/_index.md in Korean
- Translate concepts/cloud-administration/cloud-providers.md in Korean
- Translate contribute/review/for-approvers.md in Korean

Co-authored-by:    Jerry Park <jaehwa@gmail.com>
Co-authored-by:    Seokho Son <shsongist@gmail.com>
Co-authored-by:    jmyung <jesang.myung@gmail.com>
Co-authored-by:    coolguyhong <podolsmith@naver.com>
Co-authored-by:    Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by:    bluefriday <bluefriday86@gmail.com>
Co-authored-by:    SangshikLee <neolss@gmail.com>
This commit is contained in:
Jerry Park
2020-04-11 15:21:34 +09:00
committed by Claudia J.Kang
parent c74ce882ec
commit ca62e21766
67 changed files with 4827 additions and 313 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/administer-cluster/highly-available-master.md
+1 -1
View File
@@ -6,7 +6,7 @@ content_template: templates/task
{{% capture overview %}}
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다.
이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다.
content/ko/docs/tasks/administer-cluster/kubeadm/_index.md
Executable
+4
View File
@@ -0,0 +1,4 @@
---
title: "kubeadm으로 관리하기"
weight: 10
---
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+443
View File
@@ -0,0 +1,443 @@
---
title: kubeadm 클러스터 업그레이드
content_template: templates/task
weight: 20
min-kubernetes-server-version: 1.18
---
{{% capture overview %}}
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
이 페이지 대신 다음의 페이지들을 참고한다.
- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
- [kubeadm 클러스터를 1.13에서 1.14로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
추상적인 업그레이드 작업 절차는 다음과 같다.
1. 기본 컨트롤 플레인 노드를 업그레이드한다.
1. 추가 컨트롤 플레인 노드를 업그레이드한다.
1. 워커(worker) 노드를 업그레이드한다.
{{% /capture %}}
{{% capture prerequisites %}}
- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다.
- 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다.
`kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다.
### 추가 정보
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
- 하나의 MINOR 버전에서 다음 MINOR 버전으로,
또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다.
예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다.
{{% /capture %}}
{{% capture steps %}}
## 업그레이드할 버전 결정
1. 최신의 안정 버전인 1.18을 찾는다.
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
apt update
apt-cache madison kubeadm
# 목록에서 최신 버전 1.18을 찾는다
# 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 목록에서 최신 버전 1.18을 찾는다
# 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{< /tabs >}}
## 컨트롤 플레인 노드 업그레이드
### 첫 번째 컨트롤 플레인 노드 업그레이드
1. 첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다.
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. 다운로드하려는 버전이 잘 받아졌는지 확인한다.
```shell
kubeadm version
```
1. 컨트롤 플레인 노드를 드레인(drain)한다.
```shell
# <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
kubectl drain <cp-node-name> --ignore-daemonsets
```
1. 컨트롤 플레인 노드에서 다음을 실행한다.
```shell
sudo kubeadm upgrade plan
```
다음과 비슷한 출력이 표시되어야 한다.
```
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/versions] Latest stable version: v1.18.0
[upgrade/versions] Latest version in the v1.17 series: v1.18.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.17.3 v1.18.0
Upgrade to the latest version in the v1.17 series:
COMPONENT CURRENT AVAILABLE
API Server v1.17.3 v1.18.0
Controller Manager v1.17.3 v1.18.0
Scheduler v1.17.3 v1.18.0
Kube Proxy v1.17.3 v1.18.0
CoreDNS 1.6.5 1.6.7
Etcd 3.4.3 3.4.3-0
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.18.0
_____________________________________________________________________
```
이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
{{< note >}}
또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다.
자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다.
{{</ note >}}
1. 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다.
```shell
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v1.18.x
```
다음과 비슷한 출력이 표시되어야 한다.
```
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.18.0"
[upgrade/versions] Cluster version: v1.17.3
[upgrade/versions] kubeadm version: v1.18.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"...
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
[upgrade/etcd] Upgrading to TLS for etcd
[upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012"
W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46
Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18
Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366
Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
1. CNI 제공자 플러그인을 수동으로 업그레이드한다.
CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다.
[애드온](/docs/concepts/cluster-administration/addons/) 페이지에서
사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다.
CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.
1. 컨트롤 플레인 노드에 적용된 cordon을 해제한다.
```shell
# <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
kubectl uncordon <cp-node-name>
```
### 추가 컨트롤 플레인 노드 업그레이드
1. 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다.
```
sudo kubeadm upgrade node
```
아래 명령 대신 위의 명령을 사용한다.
```
sudo kubeadm upgrade apply
```
또한 `sudo kubeadm upgrade plan` 은 필요하지 않다.
### kubelet과 kubectl 업그레이드
1. 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. kubelet을 다시 시작한다.
```shell
sudo systemctl restart kubelet
```
## 워커 노드 업그레이드
워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서,
한 번에 하나의 노드 또는 한 번에 몇 개의 노드로 실행해야 한다.
### kubeadm 업그레이드
1. 모든 워커 노드에서 kubeadm을 업그레이드한다.
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
### 노드 드레인
1. 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
```shell
# <node-to-drain>을 드레이닝하려는 노드 이름으로 바꾼다.
kubectl drain <node-to-drain> --ignore-daemonsets
```
다음과 비슷한 출력이 표시되어야 한다.
```
node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained
```
### kubelet 구성 업그레이드
1. 다음의 명령을 호출한다.
```shell
sudo kubeadm upgrade node
```
### kubelet과 kubectl 업그레이드
1. 모든 워커 노드에서 kubelet 및 kubectl을 업그레이드한다.
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.18.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
1. kubelet을 다시 시작한다.
```shell
sudo systemctl restart kubelet
```
### 노드에 적용된 cordon 해제
1. 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다.
```shell
# <node-to-drain>을 노드의 이름으로 바꾼다.
kubectl uncordon <node-to-drain>
```
## 클러스터 상태 확인
모든 노드에서 kubelet을 업그레이드 한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다.
```shell
kubectl get nodes
```
모든 노드에 대해 `STATUS` 열에 `Ready` 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다.
{{% /capture %}}
## 장애 상태에서의 복구
예를 들어 `kubeadm upgrade` 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, `kubeadm upgrade` 를 다시 실행할 수 있다.
이 명령은 멱등성을 보장하며 결국 실제 상태가 선언한 의도한 상태인지 확인한다.
잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다.
업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다.
- `kubeadm-backup-etcd-<date>-<time>`
- `kubeadm-backup-manifests-<date>-<time>`
`kubeadm-backup-etcd` 는 컨트롤 플레인 노드에 대한 로컬 etcd 멤버 데이터의 백업을 포함한다.
etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, 이 폴더의 내용을
`/var/lib/etcd` 에서 수동으로 복원할 수 있다. 외부 etcd를 사용하는 경우 이 백업 폴더는 비어있다.
`kubeadm-backup-manifests` 는 컨트롤 플레인 노드에 대한 정적 파드 매니페스트 파일의 백업을 포함한다.
업그레이드가 실패하고 자동 롤백이 작동하지 않으면, 이 폴더의 내용을
`/etc/kubernetes/manifests` 에서 수동으로 복원할 수 있다. 어떤 이유로 특정 컴포넌트의 업그레이드 전
매니페스트 파일과 업그레이드 후 매니페스트 파일 간에 차이가 없는 경우, 백업 파일은 기록되지 않는다.
## 작동 원리
`kubeadm upgrade apply` 는 다음을 수행한다.
- 클러스터가 업그레이드 가능한 상태인지 확인한다.
- API 서버에 접근할 수 있다
- 모든 노드가 `Ready` 상태에 있다
- 컨트롤 플레인이 정상적으로 동작한다
- 버전 차이(skew) 정책을 적용한다.
- 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
- 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
- API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
`kubeadm upgrade node` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다.
- 클러스터에서 kubeadm `ClusterConfiguration` 을 가져온다.
- 선택적으로 kube-apiserver 인증서를 백업한다.
- 컨트롤 플레인 컴포넌트에 대한 정적 파드 매니페스트를 업그레이드한다.
- 이 노드의 kubelet 구성을 업그레이드한다.
`kubeadm upgrade node` 는 워커 노드에서 다음을 수행한다.
- 클러스터에서 kubeadm `ClusterConfiguration` 을 가져온다.
- 이 노드의 kubelet 구성을 업그레이드한다.
content/ko/docs/tasks/configure-pod-container/configure-volume-storage.md
+145
View File
@@ -0,0 +1,145 @@
---
title: 스토리지의 볼륨을 사용하는 파드 구성
content_template: templates/task
weight: 50
---
{{% capture overview %}}
이 페이지는 스토리지의 볼륨을 사용하는 파드를 구성하는 방법을 설명한다.
컨테이너 파일 시스템은 컨테이너가 살아있는 동안만 존재한다. 따라서
컨테이너가 종료되고 재시작할 때, 파일 시스템 변경사항이 손실된다. 컨테이너와
독립적이며 보다 일관된 스토리지를 위해 사용자는 [볼륨](/ko/docs/concepts/storage/volumes/)을
사용할 수 있다. 이것은 레디스(Redis)와 같은 키-값 저장소나
데이터베이스와 같은 스테이트풀 애플리케이션에 매우 중요하다.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## 파드에 볼륨 구성
이 연습에서는 하나의 컨테이너를 실행하는 파드를 생성한다. 이 파드는
컨테이너가
종료되고, 재시작 하더라도 파드의 수명동안 지속되는 [emptyDir](/ko/docs/concepts/storage/volumes/#emptydir)
유형의 볼륨이 있다.
파드의 구성 파일은 다음과 같다.
{{< codenew file="pods/storage/redis.yaml" >}}
1. 파드 생성
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
```
1. 파드의 컨테이너가 Running 중인지 확인하고, 파드의 변경사항을
지켜본다.
```shell
kubectl get pod redis --watch
```
출력은 이와 유사하다.
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
```
1. 다른 터미널에서 실행 중인 컨테이너의 셸을 획득한다.
```shell
kubectl exec -it redis -- /bin/bash
```
1. 셸에서 `/data/redis` 로 이동하고, 파일을 생성한다.
```shell
root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file
```
1. 셸에서 실행 중인 프로세스 목록을 확인한다.
```shell
root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux
```
출력은 이와 유사하다.
```shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
```
1. 셸에서 Redis 프로세스를 강제종료(kill)한다.
```shell
root@redis:/data/redis# kill <pid>
```
여기서 `<pid>`는 Redis 프로세스 ID(PID) 이다.
1. 원래 터미널에서, Redis 파드의 변경을 지켜본다. 결국,
다음과 유사한 것을 보게 될 것이다.
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
```
이때, 컨테이너는 종료되고 재시작된다. 이는
Redis 파드의
[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)는
`Always` 이기 때문이다.
1. 재시작된 컨테이너의 셸을 획득한다.
```shell
kubectl exec -it redis -- /bin/bash
```
1. 셸에서 `/data/redis` 로 이동하고, `test-file` 이 여전히 존재하는지 확인한다.
```shell
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file
```
1. 이 연습을 위해 생성한 파드를 삭제한다.
```shell
kubectl delete pod redis
```
{{% /capture %}}
{{% capture whatsnext %}}
* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 참고한다.
* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 참고한다.
* 쿠버네티스는 `emptyDir` 이 제공하는 로컬 디스크 스토리지 뿐만 아니라,
중요한 데이터에 선호하는 GCE의 PD, EC2의 EBS를 포함해서
네트워크 연결 스토리지(NAS) 솔루션을 지원하며,
노드의 디바이스 마운트, 언마운트와 같은 세부사항을 처리한다.
자세한 내용은 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고한다.
{{% /capture %}}
content/ko/docs/tasks/manage-gpus/scheduling-gpus.md
+1 -1
View File
@@ -7,7 +7,7 @@ title: GPU 스케줄링
{{% capture overview %}}
{{< feature-state state="beta" for_k8s_version="1.10" >}}
{{< feature-state state="beta" for_k8s_version="v1.10" >}}
쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인**
지원을 포함한다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -232,7 +232,7 @@ CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원
이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며,
`metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다.
또한, `AverageUtilization` 대신 `AverageValue`의 `target` 타입을,
또한, `Utilization` 대신 `AverageValue`의 `target` 타입을,
그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여
자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다.
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+1 -1
View File
@@ -71,7 +71,7 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
{{< feature-state state="deprecated" for_k8s_version="v1.11" >}}
힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨.
{{< /note >}}
content/ko/docs/tasks/tools/install-kubectl.md
+496
View File
@@ -0,0 +1,496 @@
---
title: kubectl 설치 및 설정
content_template: templates/task
weight: 10
card:
name: tasks
weight: 20
title: kubectl 설치
---
{{% capture overview %}}
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/user-guide/kubectl/)을 사용하면, 쿠버네티스 클러스터에 대해 명령을 실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며 로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는, [kubectl 개요](/docs/reference/kubectl/overview/)를 참고한다.
{{% /capture %}}
{{% capture prerequisites %}}
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
{{% /capture %}}
{{% capture steps %}}
## 리눅스에 kubectl 설치
### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치
1. 다음 명령으로 최신 릴리스를 다운로드한다.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
```
특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
2. kubectl 바이너리를 실행 가능하게 만든다.
```
chmod +x ./kubectl
```
3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
### 기본 패키지 관리 도구를 사용하여 설치
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
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
EOF
yum install -y kubectl
{{< /tab >}}
{{< /tabs >}}
### 다른 패키지 관리 도구를 사용하여 설치
{{< tabs name="other_kubectl_install" >}}
{{% tab name="Snap" %}}
[snap](https://snapcraft.io/docs/core/install) 패키지 관리자를 지원하는 Ubuntu 또는 다른 리눅스 배포판을 사용하는 경우, kubectl을 [snap](https://snapcraft.io/) 애플리케이션으로 설치할 수 있다.
```shell
snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
리눅스 상에서 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 패키지 관리자를 사용한다면, [설치](https://docs.brew.sh/Homebrew-on-Linux#install)를 통해 kubectl을 사용할 수 있다.
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## macOS에 kubectl 설치
### macOS에서 curl을 사용하여 kubectl 바이너리 설치
1. 최신 릴리스를 다운로드한다.
```
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
```
특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
2. kubectl 바이너리를 실행 가능하게 만든다.
```
chmod +x ./kubectl
```
3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
### macOS에서 Homebrew를 사용하여 설치
macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경우, Homebrew로 kubectl을 설치할 수 있다.
1. 설치 명령을 실행한다.
```
brew install kubectl
```
또는
```
brew install kubernetes-cli
```
2. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
### macOS에서 Macports를 사용하여 설치
macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하는 경우, Macports로 kubectl을 설치할 수 있다.
1. 설치 명령을 실행한다.
```
sudo port selfupdate
sudo port install kubectl
```
2. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
## Windows에 kubectl 설치
### Windows에서 curl을 사용하여 kubectl 바이너리 설치
1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다.
또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다.
2. 바이너리를 PATH가 설정된 디렉터리에 추가한다.
3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
```
kubectl version --client
```
{{< note >}}
[Windows용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다.
도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 PATH 항목 앞에 PATH 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
{{< /note >}}
### PSGallery에서 Powershell로 설치
Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.
1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다).
```
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
{{< note >}}`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.{{< /note >}}
설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다.
2. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
{{< note >}}설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다.{{< /note >}}
### Chocolatey 또는 Scoop을 사용하여 Windows에 설치
Windows에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
choco install kubernetes-cli
{{% /tab %}}
{{% tab name="scoop" %}}
scoop install kubectl
{{% /tab %}}
{{< /tabs >}}
2. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
3. 홈 디렉토리로 이동한다.
```
cd %USERPROFILE%
```
4. `.kube` 디렉터리를 생성한다.
```
mkdir .kube
```
5. 금방 생성한 `.kube` 디렉터리로 이동한다.
```
cd .kube
```
6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.
```
New-Item config -type file
```
{{< note >}}메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.{{< /note >}}
## Google Cloud SDK의 일부로 다운로드
kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.
1. [Google Cloud SDK](https://cloud.google.com/sdk/)를 설치한다.
2. `kubectl` 설치 명령을 실행한다.
```
gcloud components install kubectl
```
3. 설치한 버전이 최신 버전인지 확인한다.
```
kubectl version --client
```
## kubectl 구성 확인
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면, [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를 사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)이 필요하다. 기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
```shell
kubectl cluster-info
```
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
```shell
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
```shell
kubectl cluster-info dump
```
## 선택적 kubectl 구성
### 셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Bash(리눅스와 macOS의 다른 점 포함) 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
{{< tabs name="kubectl_autocompletion" >}}
{{% tab name="리눅스에서의 Bash" %}}
### 소개
Bash의 kubectl 완성 스크립트는 `kubectl completion bash` 명령으로 생성할 수 있다. 셸에서 완성 스크립트를 소싱(sourcing)하면 kubectl 자동 완성 기능이 활성화된다.
그러나, 완성 스크립트는 [**bash-completion**](https://github.com/scop/bash-completion)에 의존하고 있으며, 이 소프트웨어를 먼저 설치해야 한다(`type _init_completion` 을 실행하여 bash-completion이 이미 설치되어 있는지 확인할 수 있음).
### bash-completion 설치
bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](https://github.com/scop/bash-completion#installation) 참고). `apt-get install bash-completion` 또는 `yum install bash-completion` 등으로 설치할 수 있다.
위의 명령은 bash-completion의 기본 스크립트인 `/usr/share/bash-completion/bash_completion` 을 생성한다. 패키지 관리자에 따라, `~/.bashrc` 파일에서 이 파일을 수동으로 소스(source)해야 한다.
확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다.
```shell
source /usr/share/bash-completion/bash_completion
```
셸을 다시 로드하고 `type _init_completion` 을 입력하여 bash-completion이 올바르게 설치되었는지 확인한다.
### kubectl 자동 완성 활성화
이제 kubectl 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
- `~/.bashrc` 파일에서 완성 스크립트를 소싱한다.
```shell
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.
```shell
kubectl completion bash >/etc/bash_completion.d/kubectl
```
- kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.
```shell
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
bash-completion은 `/etc/bash_completion.d` 에 있는 모든 완성 스크립트를 소싱한다.
{{< /note >}}
두 방법 모두 동일하다. 셸을 다시 로드한 후, kubectl 자동 완성 기능이 작동해야 한다.
{{% /tab %}}
{{% tab name="macOS에서의 Bash" %}}
### 소개
Bash의 kubectl 완성 스크립트는 `kubectl completion bash` 로 생성할 수 있다. 이 스크립트를 셸에 소싱하면 kubectl 완성이 가능하다.
그러나 kubectl 완성 스크립트는 미리 [**bash-completion**](https://github.com/scop/bash-completion)을 설치해야 동작한다.
{{< warning>}}
bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 **작동하지 않는다**. **bash-completion v2** 와 **Bash 4.1 이상 버전** 이 필요하다. 따라서, macOS에서 kubectl 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야한다([*지침*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다.
{{< /warning >}}
### Bash 업그레이드
여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.
```shell
echo $BASH_VERSION
```
너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.
```shell
brew install bash
```
셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.
```shell
echo $BASH_VERSION $SHELL
```
Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다.
### bash-completion 설치
{{< note >}}
언급한 바와 같이, 이 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 이는 bash-completion v2를 설치한다는 것을 의미한다(Bash 3.2 및 bash-completion v1의 경우, kubectl 완성이 작동하지 않음).
{{< /note >}}
bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.
```shell
brew install bash-completion@2
```
이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다.
```shell
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
셸을 다시 로드하고 bash-completion v2가 올바르게 설치되었는지 `type _init_completion` 으로 확인한다.
### kubectl 자동 완성 활성화
이제 kubectl 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행하는 방법에는 여러 가지가 있다.
- 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다.
```shell
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다.
```shell
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다.
```shell
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile
```
- Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다.
{{< note >}}
bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다.
{{< /note >}}
어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다.
{{% /tab %}}
{{% tab name="Zsh" %}}
Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생성할 수 있다. 셸에서 완성 스크립트를 소싱하면 kubectl 자동 완성 기능이 활성화된다.
모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다.
```shell
source <(kubectl completion zsh)
```
kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.
```shell
echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc
```
셸을 다시 로드 한 후, kubectl 자동 완성 기능이 작동해야 한다.
`complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.
```shell
autoload -Uz compinit
compinit
```
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
* [Minikube 설치](/ko/docs/tasks/tools/install-minikube/)
* 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
* [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
{{% /capture %}}