From 09708662ccf9509147e3cf4fa96877a050a8476f Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Thu, 10 Dec 2020 03:47:54 +0000 Subject: [PATCH] Update outdated files in the dev-1.19-ko.7 branch --- .../cluster-administration/networking.md | 5 +- .../cluster-administration/system-metrics.md | 2 +- .../ko/docs/concepts/configuration/secret.md | 13 ++--- .../overview/working-with-objects/labels.md | 9 +-- .../ingress-controllers.md | 55 ++++++++++--------- .../concepts/storage/persistent-volumes.md | 49 ++++++++++------- .../workloads/controllers/daemonset.md | 6 -- .../feature-gates.md | 7 ++- .../ko/docs/reference/kubectl/cheatsheet.md | 3 +- .../container-runtimes.md | 2 +- .../ko/examples/application/job/cronjob.yaml | 1 + .../application/mysql/mysql-configmap.yaml | 8 +-- .../application/mysql/mysql-services.yaml | 6 +- .../application/mysql/mysql-statefulset.yaml | 36 ++++++------ 14 files changed, 105 insertions(+), 97 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index a24b3bb93f..b72d38a360 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -55,11 +55,12 @@ weight: 50 주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고 프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다. -쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내 +쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내 컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두 `localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한 `Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도 -VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. +VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 +한다. 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index e4dedb068a..a16ba02265 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -103,7 +103,7 @@ kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVID 액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다. -[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. +[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. ## 컴포넌트 메트릭 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index e75beb8666..b7392f0843 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -134,7 +134,7 @@ data: [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다. 또한 파드에서 서비스 어카운트를 참조하는 방법을 -[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의 +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의 `automountServiceAccountToken` 필드와 `serviceAccountName` 필드를 통해 확인할 수 있다. @@ -152,7 +152,7 @@ data: 인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지 확실히 확인해야 한다. -`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의 +`kubernetes.io/dockerconfigjson` 타입은 `~/.dockercfg` 의 새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을 따르는 직렬화 된 JSON의 저장을 위해 디자인되었다. 이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를 @@ -347,22 +347,21 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` -부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다. +부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다. - `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. -- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 +- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. - `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 사용하는 절대 UTC 시간. 선택 사항. - `usage-bootstrap-`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 불리언(boolean) 플래그. -- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될 +- `auth-extra-groups`: `system:bootstrappers` 그룹에 추가로 인증될 쉼표로 구분된 그룹 이름 목록. 위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일 -수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는 -동일한 시크릿을 생성할 수 있다. +수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿을 생성할 수 있다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 597bf0e48d..1e0d86a97b 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -138,10 +138,11 @@ partition !partition ``` -첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다. -두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다. -세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다. -네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다. +* 첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다. +* 두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다. +* 세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다. +* 네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다. + 마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다. _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 653993a485..7690669757 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -13,8 +13,8 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다. -프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 - [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. +프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와 + [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다. @@ -24,31 +24,31 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 {{% thirdparty-content %}} -* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). -* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 - [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 - [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. -* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. -* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다. -* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 - VMware에서 제공하고 지원한다. -* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. -* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 - [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. -* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. -* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. -* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다. -* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 - [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 - [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 - [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. -* [NGINX, Inc.](https://www.nginx.com/)는 - [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. -* [Traefik](https://github.com/traefik/traefik)은 - 모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, - [Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다. +* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. +* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 + 컨트롤러다. +* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 + Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. +* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를 + 이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다. +* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 + 오픈소스 인그레스 컨트롤러다. +* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의 + 인그레스 컨트롤러다. +* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용 + 인그레스 컨트롤러이기도 하다. +* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/) + 기반 인그레스 컨트롤러다. +* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를 + 구동하는 인그레스 컨트롤러다. +* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary) + 웹서버(프록시로 사용)와 함께 작동한다. +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. +* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 + [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다. +* [Voyager](https://appscode.com/products/voyager)는 + [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다. ## 여러 인그레스 컨트롤러 사용 @@ -73,3 +73,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. * [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). + diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index a74dd45de6..73ddc11908 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -304,26 +304,35 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다. -* GCEPersistentDisk -* AWSElasticBlockStore -* AzureFile -* AzureDisk -* CSI -* FC (파이버 채널) -* FlexVolume -* Flocker -* NFS -* iSCSI -* RBD (Ceph Block Device) -* CephFS -* Cinder (OpenStack 블록 스토리지) -* Glusterfs -* VsphereVolume -* Quobyte Volumes -* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음) -* Portworx Volumes -* ScaleIO Volumes -* StorageOS +* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store(EBS) +* [`azureDisk`](/ko/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨 +* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder(OpenStack 블록 스토리지) + (**사용 중단됨**) +* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스(CSI) +* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - 파이버 채널(FC) 스토리지 +* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume +* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 +* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 영구 디스크 +* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 +* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨 + (단일 노드 테스트 전용임. 다중-노드 클러스터에서는 동작하지 않음! + 대신 `local` 볼륨을 사용하는 것을 고려할 것) +* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI(SCSI over IP) 스토리지 +* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된 + 로컬 스토리지 디바이스. +* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - Network File System(NFS) 스토리지 +* `photonPersistentDisk` - Photon 컨트롤러 영구 디스크. + (해당 클라우드 제공자 삭제로 인해 이 볼륨 타입은 더이상 + 동작하지 않음.) +* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨 +* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 +* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device(RBD) 볼륨 +* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨 + (**사용 중단됨**) +* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨 +* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨 ## 퍼시스턴트 볼륨 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 3fd5f2830a..589fe7c1dd 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -81,12 +81,6 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. -또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 -레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 -{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 -막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 -수동으로 생성하는 것이다. - ### 오직 일부 노드에서만 파드 실행 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index bb6f839d86..fd120705a1 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -380,9 +380,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. - 자세한 내용은 [서비스 어카운트 토큰 볼륨](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)을 - 확인한다. + 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 + 사용하여 확장 토큰에 의존하는 워크로드를 모니터링할 수 있다. 이러한 워크로드가 + 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰을 끈다. + [바인딩된 서비스 어카운트 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 5e03ead888..1613791ddf 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -305,9 +305,10 @@ mynamespace # 특정 네임스페이스 kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 --dry-run=client -o yaml > pod.yaml -kubectl attach my-pod -i # 실행중인 컨테이너에 연결 +kubectl attach my-pod -i # 실행 중인 컨테이너에 연결 kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) +kubectl exec --stdin --tty my-pod -- /bin/sh # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우) kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 실행(멀티-컨테이너 경우) kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시 ``` diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index bbf5de5d82..bbd906f5f6 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -119,7 +119,7 @@ sudo apt-get update && sudo apt-get install -y containerd.io ```shell # containerd 구성 sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +sudo containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/ko/examples/application/job/cronjob.yaml b/content/ko/examples/application/job/cronjob.yaml index c9d3893027..3ca130289e 100644 --- a/content/ko/examples/application/job/cronjob.yaml +++ b/content/ko/examples/application/job/cronjob.yaml @@ -11,6 +11,7 @@ spec: containers: - name: hello image: busybox + imagePullPolicy: IfNotPresent args: - /bin/sh - -c diff --git a/content/ko/examples/application/mysql/mysql-configmap.yaml b/content/ko/examples/application/mysql/mysql-configmap.yaml index 46d34e422c..6dd50665a2 100644 --- a/content/ko/examples/application/mysql/mysql-configmap.yaml +++ b/content/ko/examples/application/mysql/mysql-configmap.yaml @@ -5,12 +5,12 @@ metadata: labels: app: mysql data: - master.cnf: | - # Apply this config only on the master. + primary.cnf: | + # Primary에만 이 구성을 적용한다. [mysqld] log-bin - slave.cnf: | - # Apply this config only on slaves. + replica.cnf: | + # 레플리카에만 이 구성을 적용한다. [mysqld] super-read-only diff --git a/content/ko/examples/application/mysql/mysql-services.yaml b/content/ko/examples/application/mysql/mysql-services.yaml index f538992566..17279dd7f9 100644 --- a/content/ko/examples/application/mysql/mysql-services.yaml +++ b/content/ko/examples/application/mysql/mysql-services.yaml @@ -1,4 +1,4 @@ -# Headless service for stable DNS entries of StatefulSet members. +# 스테이트풀셋 멤버의 안정적인 DNS 엔트리를 위한 헤드리스 서비스. apiVersion: v1 kind: Service metadata: @@ -13,8 +13,8 @@ spec: selector: app: mysql --- -# Client service for connecting to any MySQL instance for reads. -# For writes, you must instead connect to the master: mysql-0.mysql. +# 읽기용 MySQL 인스턴스에 연결하기 위한 클라이언트 서비스. +# 쓰기용은 Primary인 mysql-0.mysql에 대신 연결해야 한다. apiVersion: v1 kind: Service metadata: diff --git a/content/ko/examples/application/mysql/mysql-statefulset.yaml b/content/ko/examples/application/mysql/mysql-statefulset.yaml index b69af02c59..5c6259a66d 100644 --- a/content/ko/examples/application/mysql/mysql-statefulset.yaml +++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml @@ -21,17 +21,17 @@ spec: - "-c" - | set -ex - # Generate mysql server-id from pod ordinal index. + # 파드의 원래 인덱스에서 mysql server-id를 생성. [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf - # Add an offset to avoid reserved server-id=0 value. + # 예약된 server-id=0 값을 피하기 위해 오프셋 추가. echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf - # Copy appropriate conf.d files from config-map to emptyDir. + # config-map에서 emptyDir로 적당한 conf.d 파일들을 복사. if [[ $ordinal -eq 0 ]]; then - cp /mnt/config-map/master.cnf /mnt/conf.d/ + cp /mnt/config-map/primary.cnf /mnt/conf.d/ else - cp /mnt/config-map/slave.cnf /mnt/conf.d/ + cp /mnt/config-map/replica.cnf /mnt/conf.d/ fi volumeMounts: - name: conf @@ -45,15 +45,15 @@ spec: - "-c" - | set -ex - # Skip the clone if data already exists. + # 데이터가 이미 존재하면 복제 생략. [[ -d /var/lib/mysql/mysql ]] && exit 0 - # Skip the clone on master (ordinal index 0). + # Primary에 복제 생략(ordinal index 0). [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} [[ $ordinal -eq 0 ]] && exit 0 - # Clone data from previous peer. + # 이전 피어(peer)에서 데이터 복제. ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql - # Prepare the backup. + # 백업 준비. xtrabackup --prepare --target-dir=/var/lib/mysql volumeMounts: - name: data @@ -88,7 +88,7 @@ spec: timeoutSeconds: 5 readinessProbe: exec: - # Check we can execute queries over TCP (skip-networking is off). + # TCP 상에서 쿼리를 실행할 수 있는지 확인(skip-networking은 off). command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] initialDelaySeconds: 5 periodSeconds: 2 @@ -105,22 +105,22 @@ spec: set -ex cd /var/lib/mysql - # Determine binlog position of cloned data, if any. + # 복제된 데이터의 binlog 위치를 확인. if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in - # Ignore xtrabackup_binlog_info in this case (it's useless). + # 이 경우에는 xtrabackup_binlog_info는 무시(필요없음). rm -f xtrabackup_slave_info xtrabackup_binlog_info elif [[ -f xtrabackup_binlog_info ]]; then - # We're cloning directly from master. Parse binlog position. + # Primary로부터 직접 복제함. binlog 위치를 파싱. [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 rm -f xtrabackup_binlog_info xtrabackup_slave_info echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in fi - # Check if we need to complete a clone by starting replication. + # Replication을 시작하여 복제를 완료해야 하는지 확인. if [[ -f change_master_to.sql.in ]]; then echo "Waiting for mysqld to be ready (accepting connections)" until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done @@ -133,11 +133,11 @@ spec: MASTER_PASSWORD='', \ MASTER_CONNECT_RETRY=10; \ START SLAVE;" || exit 1 - # In case of container restart, attempt this at-most-once. + # 컨테이너가 다시 시작하는 경우, 이 작업을 한번만 시도한다. mv change_master_to.sql.in change_master_to.sql.orig fi - # Start a server to send backups when requested by peers. + # 피어가 요청할 때 서버를 시작하여 백업을 보냄. exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \ "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root" volumeMounts: