From 5790f7ab037dafdc7e1b09b9ce25b5795982c818 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 31 May 2022 11:31:44 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.24-ko.1 M89-M98 --- .../container-runtimes.md | 352 +++++------------- .../production-environment/tools/kops.md | 2 +- .../tools/kubeadm/control-plane-flags.md | 7 +- .../tools/kubeadm/install-kubeadm.md | 73 ++-- .../windows/user-guide-windows-containers.md | 15 +- .../access-cluster.md | 74 ++-- .../ingress-minikube.md | 14 +- .../web-ui-dashboard.md | 4 +- 8 files changed, 190 insertions(+), 351 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index b5ec7c8423..3853e60cdc 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -8,21 +8,21 @@ weight: 20 --- +{{% dockershim-removal %}} + 파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고 노드 설정 관련 작업을 설명한다. - - 쿠버네티스 {{< skew currentVersion >}}에서는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는 런타임을 사용해야 한다. 더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다. -이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 -세부 정보가 있다. +이 페이지는 쿠버네티스에서 +여러 공통 컨테이너 런타임을 사용하는 방법에 대한 개요를 제공한다. - [containerd](#containerd) - [CRI-O](#cri-o) @@ -30,12 +30,27 @@ weight: 20 - [미란티스 컨테이너 런타임](#mcr) {{< note >}} -다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. +쿠버네티스 v1.24 이전 릴리스는 +_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-deprecation-affects-you/) 문서를 확인한다. +dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, +[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다. + +v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면, +해당 버전의 문서를 참고한다. {{< /note >}} + + + ## cgroup 드라이버 -Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. +리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은 +프로세스에 할당된 리소스를 제한하는데 사용된다. 리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인 경우, init 프로세스는 root control group(`cgroup`)을 @@ -64,7 +79,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. 교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} -## cgroup v2 +### Cgroup 버전 2 {#cgroup-v2} cgroup v2는 cgroup Linux API의 다음 버전이다. cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다. @@ -102,8 +117,8 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 ### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기 -kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면 -[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. +기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면, +[cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. ## CRI 버전 지원 {#cri-versions} @@ -120,95 +135,47 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된 ### containerd -이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. +이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다. 다음 명령을 사용하여 시스템에 containerd를 설치한다. -필수 구성 요소를 설치 및 구성한다. +1. 필수 구성 요소를 설치 및 구성한다. -```shell -cat <}} -{{% tab name="Linux" %}} - -1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. -각 리눅스 배포판에 대한 도커 리포지터리를 설정하고 -`containerd.io` 패키지를 설치하는 방법은 -[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. - -2. containerd 설정 + (이 지침은 리눅스 노드에만 적용된다) ```shell - sudo mkdir -p /etc/containerd - containerd config default | sudo tee /etc/containerd/config.toml + cat <}} - -#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd} +#### `systemd` cgroup 드라이버 환경 설정하기 {#containerd-systemd} `/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다. @@ -219,7 +186,7 @@ PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로 SystemdCgroup = true ``` -이 변경 사항을 적용하는 경우 containerd를 재시작한다. +이 변경 사항을 적용하려면, containerd를 재시작한다. ```shell sudo systemctl restart containerd @@ -232,176 +199,14 @@ kubeadm을 사용하는 경우, 이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다. -시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. - -{{< note >}} -CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다. -더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)를 본다. -{{< /note >}} - -필수 구성 요소를 설치하고 구성한다. - -```shell -# .conf 파일을 만들어 부팅 시 모듈을 로드한다 -cat <}} -{{% tab name="Debian" %}} - -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 -아래의 표에서 적절한 필드로 설정한다. - -| 운영 체제 | `$OS` | -| ---------------- | ----------------- | -| Debian Unstable | `Debian_Unstable` | -| Debian Testing | `Debian_Testing` | - -
-그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. -예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다. -사용자의 설치를 특정 릴리스에 고정할 수 있다. -버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다. -
- -그런 다음, 아래를 실행한다. -```shell -cat < -그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. -예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다. -사용자의 설치를 특정 릴리스에 고정할 수 있다. -버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다. -
- -그런 다음, 아래를 실행한다. -```shell -cat < -그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. -예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다. -사용자의 설치를 특정 릴리스에 고정할 수 있다. -버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다. -
- -그런 다음, 아래를 실행한다. -```shell -sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo -sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo -sudo yum install cri-o -``` - -{{% /tab %}} - -{{% tab name="openSUSE Tumbleweed" %}} - -```shell -sudo zypper install cri-o -``` -{{% /tab %}} -{{% tab name="Fedora" %}} - -`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다. -예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다. - -사용할 수 있는 버전을 찾으려면 다음을 실행한다. -```shell -sudo dnf module list cri-o -``` -CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다. - -그런 다음, 아래를 실행한다. -```shell -sudo dnf module enable cri-o:$VERSION -sudo dnf install cri-o -``` - -{{% /tab %}} -{{< /tabs >}} - -CRI-O를 시작한다. - -```shell -sudo systemctl daemon-reload -sudo systemctl enable crio --now -``` - -자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를 -참고한다. - +CRI-O를 설치하려면, [CRI-O 설치 방법](https://github.com/cri-o/cri-o/blob/main/install.md#readme)을 따른다. #### cgroup 드라이버 -CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. `cgroupfs` cgroup 드라이버로 -전환하려면, `/etc/crio/crio.conf` 를 수정하거나 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 -드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다. +CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다. +`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나 +`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다. +예를 들면 다음과 같다. ```toml [crio.runtime] @@ -410,27 +215,27 @@ cgroup_manager = "cgroupfs" ``` 또한 `cgroupfs` 와 함께 CRI-O를 사용할 때 `pod` 값으로 설정해야 하는 -변경된 `conmon_cgroup` 에 유의한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과 +변경된 `conmon_cgroup` 에 유의해야 한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과 CRI-O의 cgroup 드라이버 구성을 동기화 상태로 유지해야 한다. +CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다. + ### 도커 엔진 {#docker} -도커 엔진은 모든 것을 시작한 컨테이너 런타임이다. -이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다. -[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서 -이 런타임 설치의 옵션들을 확인할 수 있다. +{{< note >}} +아래의 지침은 +당신이 도커 엔진과 쿠버네티스를 통합하는 데 +[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 어댑터를 사용하고 있다고 가정한다. +{{< /note >}} -도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다. -더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다. +1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라 + 리눅스 배포판에 맞게 도커를 설치한다. -지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 통해 -쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는 -써드파티 어댑터를 찾아볼 수도 있다. +2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로 + `cri-dockerd`를 설치한다. -다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다. - -- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) +`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다. ### 미란티스 컨테이너 런타임 {#mcr} @@ -439,3 +244,14 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며, 이 컴포넌트는 MCR에 포함되어 있다. + +미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면, +[MCR 배포 가이드](https://docs.mirantis.com/mcr/20.10/install.html)를 참고한다. + +CRI 소켓의 경로를 찾으려면 +`cri-docker.socket`라는 이름의 systemd 유닛을 확인한다. + +## {{% heading "whatsnext" %}} + +컨테이너 런타임과 더불어, 클러스터에는 +동작하는 [네트워크 플러그인](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)도 필요하다. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 3bfb49380e..d4ec7f47de 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -231,7 +231,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의 ## {{% heading "whatsnext" %}} -* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/overview/)에 대해 더 알아보기. +* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/)에 대해 더 알아보기. * 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다. * 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues) diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 51d8009e83..cfba872e2a 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -24,9 +24,12 @@ kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다. {{< /note >}} - +{{< note >}} +이미 생성된 클러스터를 다시 구성하려면 +[kubeadm 클러스터 다시 구성하기](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/)를 참고한다. +{{< /note >}} -{{< feature-state for_k8s_version="v1.12" state="stable" >}} + ## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 71520bf0e8..ebd528be4d 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -15,7 +15,6 @@ card: 이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다. - ## {{% heading "prerequisites" %}} @@ -69,61 +68,69 @@ sudo sysctl --system ## 필수 포트 확인 {#check-required-ports} [필수 포트들](/ko/docs/reference/ports-and-protocols/)은 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야 -한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다. +한다. 다음과 같이 netcat과 같은 도구를 이용하여 포트가 열려 있는지 확인해 볼 수 있다. ```shell -telnet 127.0.0.1 6443 +nc 127.0.0.1 6443 ``` 사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한 플러그인 문서를 참고한다. -## 런타임 설치 {#installing-runtime} +## 컨테이너 런타임 설치 {#installing-runtime} 파드에서 컨테이너를 실행하기 위해, 쿠버네티스는 {{< glossary_tooltip term_id="container-runtime" text="컨테이너 런타임" >}}을 사용한다. -{{< tabs name="container_runtime" >}} -{{% tab name="리눅스 노드" %}} - 기본적으로, 쿠버네티스는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다. -런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여 +런타임을 지정하지 않으면, kubeadm은 잘 알려진 엔드포인트를 스캐닝하여 설치된 컨테이너 런타임을 자동으로 감지하려고 한다. -다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다. -{{< table caption = "컨테이너 런타임과 소켓 경로" >}} -| 런타임 | 유닉스 도메인 소켓 경로 | -|------------|-----------------------------------| -| 도커 | `/var/run/dockershim.sock` | -| containerd | `/run/containerd/containerd.sock` | -| CRI-O | `/var/run/crio/crio.sock` | +컨테이너 런타임이 여러 개 감지되거나 하나도 감지되지 않은 경우, +kubeadm은 에러를 반환하고 사용자가 어떤 것을 사용할지를 명시하도록 요청할 것이다. + +더 많은 정보는 +[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 참고한다. + +{{< note >}} +도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인 +[CRI](/docs/concepts/architecture/cri/)를 만족하지 않는다. +이러한 이유로, 추가 서비스인 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)가 설치되어야 한다. +cri-dockerd는 쿠버네티스 버전 1.24부터 kubelet에서 [제거](/dockershim)된 +기존 내장 도커 엔진 지원을 기반으로 한 프로젝트이다. +{{< /note >}} + +아래 표는 지원 운영 체제에 대한 알려진 엔드포인트를 담고 있다. + +{{< tabs name="container_runtime" >}} +{{% tab name="리눅스" %}} + +{{< table >}} +| 런타임 | 유닉스 도메인 소켓 경로 | +|------------------------------------|----------------------------------------------| +| containerd | `unix:///var/run/containerd/containerd.sock` | +| CRI-O | `unix:///var/run/crio/crio.sock` | +| 도커 엔진 (cri-dockerd 사용) | `unix:///var/run/cri-dockerd.sock` | {{< /table >}} -
-도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서 -도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기 -때문이다. -다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다. - -kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다. - -자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 -참고한다. {{% /tab %}} -{{% tab name="다른 운영 체제" %}} -기본적으로, kubeadm은 컨테이너 런타임으로 {{< glossary_tooltip term_id="docker" >}}를 사용한다. -kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다. -자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 -참고한다. +{{% tab name="윈도우" %}} + +{{< table >}} +| 런타임 | 윈도우 네임드 파이프(named pipe) 경로 | +|------------------------------------|----------------------------------------------| +| containerd | `npipe:////./pipe/containerd-containerd` | +| 도커 엔진 (cri-dockerd 사용) | `npipe:////./pipe/cri-dockerd` | +{{< /table >}} + {{% /tab %}} {{< /tabs >}} - ## kubeadm, kubelet 및 kubectl 설치 모든 머신에 다음 패키지들을 설치한다. @@ -217,6 +224,10 @@ sudo systemctl enable --now kubelet - 구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다. + - 사용 중인 레드햇 배포판이 `basearch`를 해석하지 못하여 `baseurl`이 실패하면, `\$basearch`를 당신의 컴퓨터의 아키텍처로 치환한다. + `uname -m` 명령을 실행하여 해당 값을 확인한다. + 예를 들어, `x86_64`에 대한 `baseurl` URL은 `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64` 이다. + {{% /tab %}} {{% tab name="패키지 매니저를 사용하지 않는 경우" %}} CNI 플러그인 설치(대부분의 파드 네트워크에 필요) diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index 3331c07216..eeeb6bc09b 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -29,7 +29,7 @@ weight: 75 포함하는 쿠버네티스 클러스터를 생성한다. * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. -[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. +[Kubectl 커맨드](/ko/docs/reference/kubectl/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다. ## 시작하기: 윈도우 컨테이너 배포하기 @@ -160,21 +160,28 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. - {{< note >}} + + `IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, 파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). 리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. 윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `windows`로 설정한다. -스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다. +{{< note >}} +1.24부터, `IdentifyPodOS` 기능은 베타 단계이며 기본적으로 활성화되어 있다. +{{< /note >}} + +스케줄러는 파드를 노드에 할당할 때 +`.spec.os.name` 필드의 값을 사용하지 않는다. 컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면, [파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는 일반적인 쿠버네티스 메카니즘을 사용해야 한다. + `.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에, 윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트, 톨러레이션 및 노드 셀렉터가 여전히 필요하다. - {{< /note >}} + ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 46003991ae..4a36bf1c0a 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -27,8 +27,8 @@ kubectl config view ``` [여기](/ko/docs/reference/kubectl/cheatsheet/)에서 -kubectl 사용 예시를 볼 수 있으며, 완전한 문서는 -[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다. +`kubectl` 사용 예시를 볼 수 있으며, 완전한 문서는 +[kubectl 레퍼런스](/ko/docs/reference/kubectl/)에서 확인할 수 있다. ## REST API에 직접 접근 @@ -86,12 +86,36 @@ curl http://localhost:8080/api/ ### kubectl proxy를 사용하지 않음 -기본 서비스 어카운트의 토큰을 얻어내려면 `kubectl describe secret...`을 grep/cut과 함께 사용한다. +`kubectl apply` 및 `kubectl describe secret...` 명령과 grep/cut을 활용하여 기본 서비스 어카운트의 토큰을 생성한다. + +먼저, 기본 서비스어카운트를 위한 토큰을 요청하는 시크릿을 생성한다. + +```shell +kubectl apply -f - </dev/null; do + echo "waiting for token..." >&2 + sleep 1 +done +``` + +결과를 캡처하여 생성된 토큰을 사용한다. ```shell APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ") -SECRET_NAME=$(kubectl get secrets | grep ^default | cut -f1 -d ' ') -TOKEN=$(kubectl describe secret $SECRET_NAME | grep -E '^token' | cut -f2 -d':' | tr -d " ") +TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ") curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure ``` @@ -117,8 +141,7 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure ```shell APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') -SECRET_NAME=$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode) +TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode) curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure ``` @@ -181,40 +204,17 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 ## 파드에서 API 접근 -파드에서 API를 접속한다면 apiserver의 -위치지정과 인증은 다소 다르다. +파드에서 API에 접근하는 경우, +API 서버를 찾고 인증하는 방식이 약간 다를 수 있다. -파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 -`kubernetes.default.svc` DNS 네임을 사용하는 것이다. -이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다. - -apiserver 인증에 추천되는 방식은 -[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) -인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 -해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 -`/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다. - -사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 -`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 -apiserver의 인증서 제공을 검증하는데 사용되어야 한다. - -마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 -`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다. - -파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다. - - - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, - 컨테이너 내부에서 백그라운드 프로세스로 실행한다. - 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여 - 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. - - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. - 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) - -각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다. +더 자세한 내용은 +[파드 내에서 쿠버네티스 API에 접근](/ko/docs/tasks/run-application/access-api-from-pod/)을 참조한다. ## 클러스터에서 실행되는 서비스로 접근 -이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다. +이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. +쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 +[클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다. ## redirect 요청하기 diff --git a/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md index a59c25d390..f4d24f4e49 100644 --- a/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/ko/docs/tasks/access-application-cluster/ingress-minikube.md @@ -240,13 +240,13 @@ storage-provisioner 1/1 Running 0 2m 하단에 다음 줄을 추가한다. ```yaml - - path: /v2 - pathType: Prefix - backend: - service: - name: web2 - port: - number: 8080 + - path: /v2 + pathType: Prefix + backend: + service: + name: web2 + port: + number: 8080 ``` 1. 변경 사항을 적용한다. diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index ae1cf08fdd..30d72d4015 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -2,6 +2,8 @@ + + title: 쿠버네티스 대시보드를 배포하고 접속하기 description: >- 웹 UI(쿠버네티스 대시보드)를 배포하고 접속한다. @@ -35,7 +37,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근