From 03f5e9f846e1fc52217d7ad1dfeac33e347f3d0c Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Wed, 26 Feb 2020 11:08:26 +0800 Subject: [PATCH 01/32] update zh-trabns content/zh/docs/concepts/services-networking/ingress-controllers.md (#19130) --- .../ingress-controllers.md | 249 ++++++++++-------- 1 file changed, 133 insertions(+), 116 deletions(-) diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index b427403eba..c6bdeccd00 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -1,116 +1,133 @@ ---- -title: Ingress 控制器 -content_template: templates/concept -weight: 40 ---- - -{{% capture overview %}} - - - -为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 - -与其他类型的控制器不同，它们是作为 `kube-controller-manager` 二进制文件的一部分运行的，而 Ingress 控制器不是随集群自动启动的。 -通过此页面可选择最适合您的集群的 ingress 控制器实现。 - -Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 - [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 - -{{% /capture %}} - -{{% capture body %}} - - -## 其他控制器 - -* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress - 控制器，有着来自 [Datawire](https://www.datawire.io/) [社区](https://www.getambassador.io/docs)或[商业](https://www.getambassador.io/pro/)的支持。 -* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护. -* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。 -* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 -* F5 Networks 为 [用于 Kubernetes 的 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) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 -* [HAProxy Technologies](https://www.haproxy.com/) 为 [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/) 提供支持和运维服务。 -* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 -* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。 -* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。 -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP路由器和反向代理，用于服务组合，包括诸如Kubernetes Ingress之类的用例，被设计为用于构建自定义代理的库。 -* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 - （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 - - -## 使用多个 Ingress 控制器 - -你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 -创建 ingress 时，应该使用适当的 -[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress -以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 - -如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 - -理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 - -{{< note >}} - -确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 -{{< /note >}} - -{{% /capture %}} - -{{% capture whatsnext %}} - -* 了解更多关于 [Ingress](/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 -{{% /capture %}} +--- +title: Ingress 控制器 +content_template: templates/concept +weight: 40 +--- + + + +{{% capture overview %}} + + + +为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 + +与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 +基于此页面，您可选择最适合您的集群的 ingress 控制器实现。 + +Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) +和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 + +{{% /capture %}} + +{{% capture body %}} + + +## 其他控制器 + + +* [AKS 应用程序网关 Ingress 控制器]使用 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用[AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。 +* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress + 控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。 +* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护。 +* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 ingress。 +* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 ingress 控制器，它由 VMware 提供和支持。 +* Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 +* F5 Networks 为 [用于 Kubernetes 的 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) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 +* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、由社区驱动的 Ingress 控制器。 +* [HAProxy Technologies](https://www.haproxy.com/) 为[用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。 +* 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 +* [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。 +* [NGINX, Inc.](https://www.nginx.com/) 为[用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)提供支持和维护。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 +* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 + （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket），并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 + + +## 使用多个 Ingress 控制器 + + + +你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 +创建 ingress 时，应该使用适当的 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress +以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。 + +如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。 + +理想情况下，所有 ingress 控制器都应满足此规范，但各种 ingress 控制器的操作略有不同。 + + +{{< note >}} +确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 +{{< /note >}} + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 进一步了解 [Ingress](/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/docs/tasks/access-application-cluster/ingress-minikube)。 +{{% /capture %}} From 88de2a0586d41174ec51c46cd1dc1c84747f8d95 Mon Sep 17 00:00:00 2001 From: Tobias Liese <56112387+SR-Lut3t1um@users.noreply.github.com> Date: Wed, 26 Feb 2020 11:48:25 +0100 Subject: [PATCH 02/32] fixed typo (#19202) --- content/de/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/concepts/containers/images.md b/content/de/docs/concepts/containers/images.md index 98e012640c..8f41b0c2e1 100644 --- a/content/de/docs/concepts/containers/images.md +++ b/content/de/docs/concepts/containers/images.md @@ -96,7 +96,7 @@ Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/ Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind. -Es muss einfah nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden. +Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden. Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen. From f75df43c74ed1e2acf0faaaee40579c5c464f424 Mon Sep 17 00:00:00 2001 From: Taylor Dolezal Date: Wed, 26 Feb 2020 23:21:19 -0800 Subject: [PATCH 03/32] Add onlydole to EN sections, remove duplicate entry (#19332) --- OWNERS_ALIASES | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index bf898fed46..291db36bf2 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -30,7 +30,6 @@ aliases: - onlydole - parispittman - vonguard - - onlydole sig-docs-de-owners: # Admins for German content - bene2k1 - mkorbi @@ -48,6 +47,7 @@ aliases: - kbarnard10 - kbhawkey - makoscafee + - onlydole - Rajakavitha1 - sftim - steveperry-53 @@ -64,6 +64,7 @@ aliases: - kbarnard10 - kbhawkey - makoscafee + - onlydole - rajakavitha1 - sftim - steveperry-53 From 91333c47e5ec70c69deb13d3fac19573c3925a2f Mon Sep 17 00:00:00 2001 From: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Date: Thu, 27 Feb 2020 16:29:21 +0800 Subject: [PATCH 04/32] Update apparmor.md (#19322) --- content/zh/docs/tutorials/clusters/apparmor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/clusters/apparmor.md b/content/zh/docs/tutorials/clusters/apparmor.md index 8bb34517f5..627a52ede9 100644 --- a/content/zh/docs/tutorials/clusters/apparmor.md +++ b/content/zh/docs/tutorials/clusters/apparmor.md @@ -424,7 +424,7 @@ Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载 * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). --> * 通过在每个节点上运行 Pod 的[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。 -* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或图像。 +* 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或镜像。 * 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。 -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다. +장치 플러그인은 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}에 +리소스를 알리기에 워크로드 파드는 해당 파드가 실행중인 +노드와 관련된 하드웨어 기능에 접근할 수 있다. +장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나, +각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다. + +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +의 더 자세한 정보를 +본다 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 071669a6c8..ccac6c32d1 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -140,7 +140,7 @@ EOF # 기본 출력을 위한 Get 커맨드 kubectl get services # 네임스페이스 내 모든 서비스의 목록 조회 kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회 -kubectl get pods -o wide # 네임스페이스 내 모든 파드의 상세 목록 조회 +kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회 kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회 kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회 kubectl get pod my-pod -o yaml # 파드의 YAML 조회 @@ -156,9 +156,8 @@ kubectl get services --sort-by=.metadata.name # 재시작 횟수로 정렬된 파드의 목록 조회 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회 - -kubectl get pv -n test --sort-by=.spec.capacity.storage +# PersistentVolumes을 용량별로 정렬해서 조회 +kubectl get pv --sort-by=.spec.capacity.storage # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회 kubectl get pods --selector=app=cassandra -o \ diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f02188813b..3cc93f7c7f 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -69,6 +69,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | {{% /capture %}} diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 668684fa03..0ece7e3661 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -37,7 +37,7 @@ card: |커뮤니티 |생태계 | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index d66ada6ea8..5bea0d3d9b 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -200,7 +200,11 @@ minikube start --vm-driver= * hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. * vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 개인용 워크스테이션에서 none 드라이버를 사용하는 것을 권장하지 않는다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) +* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) + +{{< caution >}} +`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. +{{< /caution >}} #### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index c83a13327a..e20fe5fd0a 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -73,7 +73,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## 리포지터리 설정 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 apt-get update && apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker의 공식 GPG 키 추가 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - @@ -160,6 +160,11 @@ systemctl restart docker 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. +{{< note >}} +CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다. +더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다. +{{< /note >}} + ### 선행 조건 ```shell 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 0be5cfc5ce..75929ae973 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -352,7 +352,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 - 서비스에 접근하는 데 사용되면 load balacing한다 -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드 상에서 실행된다 - UDP와 TCP를 proxy한다 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 46ca07d452..f9d87d9095 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 @@ -79,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 9f1be04977..f563fae04b 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -8,7 +8,7 @@ title: 리소스 모니터링 도구 애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, 애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. 컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), -[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 +[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다. 이 정보는 애플리케이션의 성능을 평가하고 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index d47b6e7f31..dde6650e20 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -81,7 +81,14 @@ kubectl apply -f <디렉터리>/ kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` {{< note >}} -`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. +`diff`는 `kube-apiserver`의 활성화가 필요한 +[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. + +`diff` 는 dry-run 모드에서 서버 측 적용 요청을 수행하므로, +`PATCH`, `CREATE`, 그리고 `UPDATE` 권한을 부여해야 한다. +자세한 것은 +[Dry-Run 인증](/docs/reference/using-api/api-concepts#dry-run-authorization)을 본다. + {{< /note >}} `kubectl apply`를 사용하여 오브젝트를 생성한다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 418ebb17dc..5672b7809b 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -57,14 +57,19 @@ index.php는 CPU 과부하 연산을 수행한다. ?> ``` -첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다. +첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 +시작하고 서비스로 노출시킨다. +{{< codenew file="application/php-apache.yaml" >}} + + +다음의 명령어를 실행한다. ```shell -kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80 +kubectl apply -f https://k8s.io/examples/application/php-apache.yaml ``` ``` -service/php-apache created deployment.apps/php-apache created +service/php-apache created ``` ## Horizontal Pod Autoscaler 생성 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 3f40a1b22b..4043ef3a13 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -158,15 +158,11 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은 현재 값보다 높은 `desiredReplicas` 을 제공하는 경우 HPA가 여전히 확장할 수 있음을 의미한다. -마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 -기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 -사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 -`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트 -동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한 -스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을 -사용하여 설정할 수 있고, 기본 값은 5분이다. -즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 -영향을 완만하게 한다. +마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. +컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의 +모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다. +즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 +메트릭 값의 영향을 완만하게 한다. ## API 오브젝트 @@ -213,6 +209,9 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 평가된 메트릭의 동적인 특징 때문에 레플리카 수가 자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다. +v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로 +노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다. + v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 필요성을 제거하였다. @@ -229,11 +228,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 있다. {{< /note >}} -v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds` -를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다. -[구성가능한 스케일링 -동작 지원](#구성가능한-스케일링-동작-지원)을 본다. - ## 멀티 메트릭을 위한 지원 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API @@ -284,154 +278,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. 어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과 [외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다. -## 구성가능한 스케일링 동작 지원 - -[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) -부터 `v2beta2` API는 HPA `behavior` 필드를 통해 -스케일링 동작을 구성할 수 있다. -동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown` -섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는 -스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는 -양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면 -스케일링 중 레플리카 변경 속도를 제어할 수 있다. - -### 스케일링 정책 - -스펙의 `behavior` 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다. -폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을 -허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이 -동작을 보여준다. - -```yaml -behavior: - scaleDown: - policies: - - type: Pods - value: 4 - periodSeconds: 60 - - type: Percent - value: 10 - periodSeconds: 60 -``` - -파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다. -예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는 -경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때 -다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의 -각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40 -미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에 -4개의 레플리카가 줄어든다. - -`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다. -첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다. -두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다. - -확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다. -레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다. -값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히 -비활성화 된다. - -### 안정화 윈도우 - -안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을 -다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터 -계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다. -다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다. - -```yaml -scaleDown: - stabilizationWindowSeconds: 300 -``` - -메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은 -이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다. -위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다. - -### 기본 동작 - -사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야 -하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA -알고리즘의 기존 동작과 일치한다. - -```yaml -behavior: - scaleDown: - stabilizationWindowSeconds: 300 - policies: - - type: Percent - value: 100 - periodSeconds: 15 - scaleUp: - stabilizationWindowSeconds: 0 - policies: - - type: Percent - value: 100 - periodSeconds: 15 - - type: Pods - value: 4 - periodSeconds: 15 - selectPolicy: Max -``` -안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된 -경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재 -실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링 -대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다. -스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다. -두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다 -4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다. - -### 예시: 다운스케일 안정화 윈도우 변경 - -사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해 -다음 동작이 HPA에 추가된다. - -```yaml -behavior: - scaleDown: - stabilizationWindowSeconds: 60 -``` - -### 예시: 스케일 다운 비율 제한 - -HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해 -다음 동작이 HPA에 추가된다. - -```yaml -behavior: - scaleDown: - policies: - - type: Percent - value: 10 - periodSeconds: 60 -``` - -마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택 -전략을 추가할 수 있다. - -```yaml -behavior: - scaleDown: - policies: - - type: Percent - value: 10 - periodSeconds: 60 - - type: Pods - value: 5 - periodSeconds: 60 - selectPolicy: Max -``` - -### 예시: 스케일 다운 비활성화 - -`selectPolicy` 의 `Disabled` 값은 주어진 방향으로의 스케일링을 끈다. -따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다. - -```yaml -behavior: - scaleDown: - selectPolicy: Disabled -``` - {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index e8de40ce96..b50856ff08 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -74,9 +74,17 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -{{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다. -{{< /note >}} +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. +이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. + +데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, +Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다. +[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다. + +{{< caution >}} +`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다. +`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다. +{{< /caution >}} ### 패키지를 이용하여 Minikube 설치 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 858bb59f58..e3f9246a4f 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -329,7 +329,7 @@ Events: 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다. 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다. -* 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서 +* 각 노드에서 파드를 실행하는 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 통해서 올바른 프로파일이 적재되었는지 확인한다. 예시 구현은 [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아볼 수 있다. * 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나 @@ -340,7 +340,7 @@ Events: 스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이 모든 노드에 적재되어야 한다. 대안적인 방법은 각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고, -[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/)를 이용하여 +[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/)를 이용하여 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다. ### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index e24b887509..b4209de162 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -117,7 +117,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl config view ``` - + {{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}} ## 서비스 만들기 @@ -125,14 +125,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만 접근할 수 있다. `hello-node` 컨테이너를 쿠버네티스 가상 네트워크 외부에서 접근하려면 파드를 쿠버네티스 -[*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다. +[*서비스*](/ko/docs/concepts/services-networking/service/)로 노출해야 한다. 1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출하기 ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기 원한다는 뜻이다. @@ -198,13 +198,13 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 storage-provisioner: enabled storage-provisioner-gluster: disabled ``` - + 2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server` ```shell minikube addons enable metrics-server ``` - + 다음과 유사하게 출력된다. ``` @@ -245,7 +245,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 ```shell minikube addons disable metrics-server ``` - + 다음과 유사하게 출력된다. ``` @@ -278,7 +278,7 @@ minikube delete {{% capture whatsnext %}} * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. -* [애플리케이션 배포](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다. -* [서비스 오브젝트](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. +* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. +* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. {{% /capture %}} diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 719ab6e1b7..23ba647830 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -23,8 +23,8 @@ content_template: templates/tutorial * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환 * [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소 * [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소 -* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 -* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. +* [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 +* [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. ## 전제 조건 @@ -34,7 +34,7 @@ content_template: templates/tutorial 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다. ```console -kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 ``` 출력은 다음과 같다. ``` @@ -57,7 +57,7 @@ deployment.apps/source-ip-app created ## Type=ClusterIP인 서비스에서 소스 IP 쿠버네티스 1.2부터 기본으로 제공하는 -[iptables 모드](/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 +[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다. Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다. @@ -122,7 +122,7 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또 ## Type=NodePort인 서비스에서 소스 IP -쿠버네티스 1.5부터 [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 +쿠버네티스 1.5부터 [Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다. ```console @@ -221,7 +221,7 @@ client_address=104.132.1.79 ## Type=LoadBalancer인 서비스에서 소스 IP -쿠버네티스 1.5 부터 [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 +쿠버네티스 1.5 부터 [Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는 로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에 패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를 diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 45056e8622..59fdbbc7e3 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -17,7 +17,7 @@ weight: 10 * [파드](/docs/user-guide/pods/single-container/) * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) -* [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services) +* [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) @@ -51,7 +51,7 @@ weight: 10 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)인 `nginx` 를 생성한다. {{< codenew file="application/web/web.yaml" >}} diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 10c011aa3b..72c090988c 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -29,7 +29,7 @@ weight: 30 {{% /capture %}} {{% capture objectives %}} -* 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다. +* 카산드라 헤드리스 [*서비스*](/ko/docs/concepts/services-networking/service/)를 생성하고 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다. @@ -37,7 +37,7 @@ weight: 30 {{% /capture %}} {{% capture prerequisites %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. @@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4 {{% capture lessoncontent %}} ## 카산드라 헤드리스 서비스 생성하기 -쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. +쿠버네티스 [서비스](/ko/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 1f419fdaf3..603a857a58 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -233,7 +233,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. * [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. -* [포트 포워딩](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. +* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 06dc81fed4..7486a7fe71 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -6,9 +6,9 @@ weight: 40 {{% capture overview %}} 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org) -쿠버네티스에서 [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 -[파드디스룹선버짓(PodDisruptionBudget)](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 -[파드안티어피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. +쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 +[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 +[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. {{% /capture %}} {{% capture prerequisites %}} @@ -18,12 +18,12 @@ weight: 40 - [파드](/docs/user-guide/pods/single-container/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) -- [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services) +- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [퍼시스턴트볼륨](/docs/concepts/storage/volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) -- [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) +- [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티) - [kubectl CLI](/docs/user-guide/kubectl/) 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. @@ -62,8 +62,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변 ## ZooKeeper 앙상블 생성하기 아래 메니페스트에는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services), -[서비스](/docs/concepts/services-networking/service/), +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스), +[서비스](/ko/docs/concepts/services-networking/service/), [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다. diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 78b72c9e73..0f7360273e 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -80,8 +80,17 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s - 참고: 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, - 동일한 명령어를 다시 입력한다. + {{< note >}} + + `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다. + + {{< /note >}} + + {{< note >}} + + 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다. + + {{< /note >}} 1. 서비스에 대한 자세한 정보를 확인한다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index a1f24755b8..4753c83b93 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -77,7 +77,7 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다. ### Redis 마스터 서비스 생성하기 -방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. +방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. {{< codenew file="application/guestbook/redis-master-service.yaml" >}} @@ -197,7 +197,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 ### 프론트엔드 서비스 생성하기 -서비스의 기본 유형은 [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. +서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. 게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. diff --git a/content/ko/examples/application/php-apache.yaml b/content/ko/examples/application/php-apache.yaml new file mode 100644 index 0000000000..5eb04cfb89 --- /dev/null +++ b/content/ko/examples/application/php-apache.yaml @@ -0,0 +1,39 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: php-apache +spec: + selector: + matchLabels: + run: php-apache + replicas: 1 + template: + metadata: + labels: + run: php-apache + spec: + containers: + - name: php-apache + image: k8s.gcr.io/hpa-example + ports: + - containerPort: 80 + resources: + limits: + cpu: 500m + requests: + cpu: 200m + +--- + +apiVersion: v1 +kind: Service +metadata: + name: php-apache + labels: + run: php-apache +spec: + ports: + - port: 80 + selector: + run: php-apache + diff --git a/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-all.yaml b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress From 55de25393429a94c92b98a883cbd30b0062c8eeb Mon Sep 17 00:00:00 2001 From: Yong Zhang Date: Fri, 28 Feb 2020 17:22:39 +0800 Subject: [PATCH 10/32] =?UTF-8?q?Localize=20=E2=80=9Cemail=20address?= =?UTF-8?q?=E2=80=9D=20placeholder=20on=20home=20page=20(#19359)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- i18n/en.toml | 3 +++ layouts/index.html | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/i18n/en.toml b/i18n/en.toml index b829bc87da..48c0c5f469 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -189,3 +189,6 @@ other = "Warning:" [whatsnext_heading] other = "What's next" + +[input_placeholder_email_address] +other = "email address" \ No newline at end of file diff --git a/layouts/index.html b/layouts/index.html index d3fd401d78..955bd6a934 100644 --- a/layouts/index.html +++ b/layouts/index.html @@ -25,7 +25,7 @@

{{ T "main_kubeweekly_baseline" }}


- +
From fc3a741b1e612a10ff25f3172045abfe4c5ce276 Mon Sep 17 00:00:00 2001 From: Cria Hu Date: Fri, 28 Feb 2020 18:40:38 +0800 Subject: [PATCH 11/32] Modify sentences with poor translation (#19366) --- content/zh/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/hello-minikube.md b/content/zh/docs/tutorials/hello-minikube.md index 7550f80dff..a8587d6967 100644 --- a/content/zh/docs/tutorials/hello-minikube.md +++ b/content/zh/docs/tutorials/hello-minikube.md @@ -171,7 +171,7 @@ Pod runs a Container based on the provided Docker image. --> ## 创建 Deployment -Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个容器为了管理和联网的目的而绑定在一起构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 +Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。 From 6318dbb124b3956979c52fee6ae71a0876b7c43c Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 29 Feb 2020 04:10:38 +0800 Subject: [PATCH 12/32] Resource name constraints (2) (#19119) xref: #17969, #19099, #18746 --- .../api-extension/custom-resources.md | 7 ++++++- .../workloads/controllers/daemonset.md | 6 +++++- .../workloads/controllers/deployment.md | 2 ++ .../workloads/controllers/replicaset.md | 18 +++++++++++++++++- .../workloads/controllers/statefulset.md | 5 +++++ .../configure-aggregation-layer.md | 3 +++ .../tasks/manage-daemon/rollback-daemon-set.md | 3 ++- 7 files changed, 40 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index c96ae1f5c7..15f3f7e234 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -128,7 +128,12 @@ Regardless of how they are installed, the new resources are referred to as Custo ## CustomResourceDefinitions -The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. +The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) +API resource allows you to define custom resources. +Defining a CRD object creates a new custom resource with a name and schema that you specify. +The Kubernetes API serves and handles the storage of your custom resource. +The name of a CRD object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). This frees you from writing your own API server to handle the custom resource, but the generic nature of the implementation means you have less flexibility than with diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 8627978427..f2feb36515 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -39,7 +39,8 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f {{< codenew file="controllers/daemonset.yaml" >}} -* Create a DaemonSet based on the YAML file: +Create a DaemonSet based on the YAML file: + ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` @@ -50,6 +51,9 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/), [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents. +The name of a DaemonSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section. ### Pod Template diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6e83992421..03c58c6525 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -1020,6 +1020,8 @@ can create multiple Deployments, one for each release, following the canary patt As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/), configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents. +The name of a Deployment object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 42451f0089..5e8c6d67f3 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -58,22 +58,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml ``` You can then get the current ReplicaSets deployed: + ```shell kubectl get rs ``` And see the frontend one you created: + ```shell NAME DESIRED CURRENT READY AGE frontend 3 3 3 6s ``` -You can also check on the state of the replicaset: +You can also check on the state of the ReplicaSet: + ```shell kubectl describe rs/frontend ``` And you will see output similar to: + ```shell Name: frontend Namespace: default @@ -103,11 +107,13 @@ Events: ``` And lastly you can check for the Pods brought up: + ```shell kubectl get pods ``` You should see Pod information similar to: + ```shell NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 6m36s @@ -117,11 +123,13 @@ frontend-wtsmm 1/1 Running 0 6m36s You can also verify that the owner reference of these pods is set to the frontend ReplicaSet. To do this, get the yaml of one of the Pods running: + ```shell kubectl get pods frontend-b2zdv -o yaml ``` The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field: + ```shell apiVersion: v1 kind: Pod @@ -166,11 +174,13 @@ The new Pods will be acquired by the ReplicaSet, and then immediately terminated its desired count. Fetching the Pods: + ```shell kubectl get pods ``` The output shows that the new Pods are either already terminated, or in the process of being terminated: + ```shell NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 10m @@ -181,17 +191,20 @@ pod2 0/1 Terminating 0 1s ``` If you create the Pods first: + ```shell kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml ``` And then create the ReplicaSet however: + ```shell kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml ``` You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the number of its new Pods and the original matches its desired count. As fetching the Pods: + ```shell kubectl get pods ``` @@ -213,6 +226,9 @@ For ReplicaSets, the kind is always just ReplicaSet. In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated. Refer to the first lines of the `frontend.yaml` example for guidance. +The name of a ReplicaSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). ### Pod Template diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4519cb4bec..aa6a07788b 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -109,10 +109,15 @@ In the above example: * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods. * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner. +The name of a StatefulSet object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + ## Pod Selector + You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation. ## Pod Identity + StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage. The identity sticks to the Pod, regardless of which node it's (re)scheduled on. diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index ef5f904079..037187499a 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -246,6 +246,9 @@ spec: caBundle: ``` +The name of an APIService object must be a valid +[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names). + #### Contacting the extension apiserver Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver, diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md index 7ca0a45a0f..4b1d424066 100644 --- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -132,7 +132,8 @@ NAME CONTROLLER REVISION AGE ``` Each `ControllerRevision` stores the annotations and template of a DaemonSet -revision. +revision. The name of a ControllerRevision object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). `kubectl rollout undo` takes a specific `ControllerRevision` and replaces DaemonSet template with the template stored in the `ControllerRevision`. From 723e62415fb3afde8d5191339c779b581862f79f Mon Sep 17 00:00:00 2001 From: Christoph Kleineweber Date: Sat, 29 Feb 2020 03:00:39 +0100 Subject: [PATCH 13/32] Update supported environments for Kubermatic (#19380) --- content/en/docs/setup/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 28ed6e1fcf..6c903d4e60 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -88,7 +88,7 @@ The following production environment solutions table lists the providers and the | [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | | [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | +| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | [KubeSail](https://kubesail.com/) | ✔ | | | | | | [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | | [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | From 0f5510b3be2cc60ff3e042d57ac6abdf44071a99 Mon Sep 17 00:00:00 2001 From: Jacky Wu Date: Sat, 29 Feb 2020 10:02:39 +0800 Subject: [PATCH 14/32] fix: correct the kube-proxy cluster-cidr arg typo. (#19358) --- content/en/docs/concepts/services-networking/dual-stack.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 0e34fa926f..81f45b5aed 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -55,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} From 4201f7811125d31925c186f66f038b3721e1ac2e Mon Sep 17 00:00:00 2001 From: huccshen <1171593960@qq.com> Date: Sat, 29 Feb 2020 10:04:39 +0800 Subject: [PATCH 15/32] fix: correct the kube-proxy cluster-cidr arg for zh (#19375) --- content/zh/docs/concepts/services-networking/dual-stack.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/services-networking/dual-stack.md b/content/zh/docs/concepts/services-networking/dual-stack.md index 1bb170c06c..1fe47f6889 100644 --- a/content/zh/docs/concepts/services-networking/dual-stack.md +++ b/content/zh/docs/concepts/services-networking/dual-stack.md @@ -108,7 +108,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/ * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} From 65c92bfbe34fbcc039ce9ab7789037635d08a08a Mon Sep 17 00:00:00 2001 From: Sharjeel Aziz Date: Sat, 29 Feb 2020 20:46:39 -0500 Subject: [PATCH 16/32] Minor formatting fix (#19356) Converted bullets to paragraphs to fix formatting in Advanced features and flexibility table. Signed-off-by: sharjeelaziz --- .../extend-kubernetes/api-extension/custom-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 15f3f7e234..d0b990e0da 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -184,7 +184,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes | | Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes | -| Status Subresource |
  • Finer-grained access control: user writes spec section, controller writes status section.
  • Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)
| [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | +| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes | | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | From 9cc37226cc7028c550a616d06021f4ae9023ffe7 Mon Sep 17 00:00:00 2001 From: huccshen <1171593960@qq.com> Date: Sun, 1 Mar 2020 09:52:40 +0800 Subject: [PATCH 17/32] fix: correct the kube-proxy cluster-cidr arg for ko (#19376) --- content/ko/docs/concepts/services-networking/dual-stack.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 9d58bccbd6..0c52346820 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -51,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} From 9fb7a223f8556678fd46338806e691c9d60cf9b9 Mon Sep 17 00:00:00 2001 From: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Date: Sun, 1 Mar 2020 10:26:40 +0800 Subject: [PATCH 18/32] Update basic-stateful-set.md (#19402) --- .../docs/tutorials/stateful-application/basic-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index b661ea9601..2586d8600a 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -1527,7 +1527,7 @@ storage configuration, and provisioning method, to ensure that all storage is reclaimed. --> -你需要删除本教程中用到的 PersistentVolumes 的持久化存储媒体。基于你的环境、存储配置和提供方式，按照必须的步骤保证回收所有的存储。 +你需要删除本教程中用到的 PersistentVolumes 的持久化存储介质。基于你的环境、存储配置和提供方式，按照必须的步骤保证回收所有的存储。 {{% /capture %}} From 10d195690de2fc9d31c7a578cee5cdda7bdef454 Mon Sep 17 00:00:00 2001 From: Yong Zhang Date: Sun, 1 Mar 2020 15:06:41 +0800 Subject: [PATCH 19/32] =?UTF-8?q?Localize=20=E2=80=9Cemail=20address?= =?UTF-8?q?=E2=80=9D=20placeholder=20on=20home=20page=20(#19360)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- i18n/zh.toml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/i18n/zh.toml b/i18n/zh.toml index 41a6f0c045..c42cb6c230 100644 --- a/i18n/zh.toml +++ b/i18n/zh.toml @@ -186,3 +186,6 @@ other = "警告：" [whatsnext_heading] other = "接下来" + +[input_placeholder_email_address] +other = "电子邮件地址" \ No newline at end of file From f9fccfe33817047b72411b6511da2a5fcfb312c9 Mon Sep 17 00:00:00 2001 From: Thibault Deutsch Date: Sun, 1 Mar 2020 07:08:41 +0000 Subject: [PATCH 20/32] =?UTF-8?q?Clean=20up=20=E2=80=9CNon-preempting=20Pr?= =?UTF-8?q?iorityClasses=E2=80=9D=20page=20section=20(#19273)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Use feature state for non-preempting PriorityClasses * PreemptionPolicy requires NonPreemptingPriority feature gate * Remove alpha qualifier from section title and decrease example heading level * Use singular of PriorityClass in the heading --- .../configuration/pod-priority-preemption.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 399f8b4e22..5c2edb1a0a 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -158,12 +158,9 @@ globalDefault: false description: "This priority class should be used for XYZ service pods only." ``` -### Non-preempting PriorityClasses (alpha) {#non-preempting-priority-class} +## Non-preempting PriorityClass {#non-preempting-priority-class} -1.15 adds the `PreemptionPolicy` field as an alpha feature. -It is disabled by default in 1.15, -and requires the `NonPreemptingPriority`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/ -) to be enabled. +{{< feature-state for_k8s_version="1.15" state="alpha" >}} Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, @@ -187,6 +184,10 @@ which will allow pods of that PriorityClass to preempt lower-priority pods If `PreemptionPolicy` is set to `Never`, pods in that PriorityClass will be non-preempting. +The use of the `PreemptionPolicy` field requires the `NonPreemptingPriority` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +to be enabled. + An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. @@ -194,7 +195,7 @@ The high priority job with `PreemptionPolicy: Never` will be scheduled ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free. -#### Example Non-preempting PriorityClass +### Example Non-preempting PriorityClass ```yaml apiVersion: scheduling.k8s.io/v1 From f15d40ad38b176f9512e6b1e8334f56874da4720 Mon Sep 17 00:00:00 2001 From: huccshen <1171593960@qq.com> Date: Sun, 1 Mar 2020 15:10:40 +0800 Subject: [PATCH 21/32] Added note for capacity of source volume (#19378) --- content/zh/docs/concepts/storage/volume-pvc-datasource.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/zh/docs/concepts/storage/volume-pvc-datasource.md b/content/zh/docs/concepts/storage/volume-pvc-datasource.md index d39e7128eb..c740f56a5f 100644 --- a/content/zh/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh/docs/concepts/storage/volume-pvc-datasource.md @@ -121,6 +121,14 @@ spec: name: pvc-1 ``` + + +{{< note >}} +你必须为 `spec.resources.requests.storage` 指定一个值，并且你指定的值必须大于或等于源卷的值。 +{{< /note >}} + From 1242c008a810c363e4e90239c392c702df24c0f2 Mon Sep 17 00:00:00 2001 From: Andrew Allbright Date: Sun, 1 Mar 2020 02:12:40 -0500 Subject: [PATCH 22/32] Update some instances of latin abbreviation e.g. to alternative phrases (#19182) --- content/en/docs/concepts/architecture/nodes.md | 2 +- .../docs/concepts/cluster-administration/cloud-providers.md | 2 +- .../en/docs/concepts/cluster-administration/federation.md | 2 +- content/en/docs/concepts/cluster-administration/logging.md | 2 +- content/en/docs/concepts/configuration/assign-pod-node.md | 6 +++--- .../compute-storage-net/network-plugins.md | 2 +- content/en/docs/concepts/storage/storage-classes.md | 6 +++--- .../reference/access-authn-authz/admission-controllers.md | 2 +- .../access-authn-authz/extensible-admission-controllers.md | 2 +- content/en/docs/reference/using-api/api-concepts.md | 2 +- .../tools/kubeadm/create-cluster-kubeadm.md | 2 +- .../list-all-running-container-images.md | 2 +- .../tasks/access-application-cluster/web-ui-dashboard.md | 2 +- .../custom-resource-definition-versioning.md | 2 +- .../custom-resources/custom-resource-definitions.md | 2 +- content/en/docs/tasks/administer-cluster/ip-masq-agent.md | 2 +- content/en/docs/tasks/administer-cluster/sysctl-cluster.md | 4 ++-- content/en/docs/tasks/configure-pod-container/static-pod.md | 2 +- .../configure-pod-container/translate-compose-kubernetes.md | 2 +- content/en/docs/tasks/debug-application-cluster/audit.md | 2 +- .../docs/tasks/debug-application-cluster/debug-cluster.md | 2 +- .../tasks/debug-application-cluster/logging-stackdriver.md | 2 +- 22 files changed, 27 insertions(+), 27 deletions(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 0b740ad46c..cf7bdac64b 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -157,7 +157,7 @@ controller deletes the node from its list of nodes. The third is monitoring the nodes' health. The node controller is responsible for updating the NodeReady condition of NodeStatus to ConditionUnknown when a node becomes unreachable (i.e. the node controller stops -receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting +receiving heartbeats for some reason, for example due to the node being down), and then later evicting all the pods from the node (using graceful termination) if the node continues to be unreachable. (The default timeouts are 40s to start reporting ConditionUnknown and 5m after that to start evicting pods.) The node controller diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 9c031807e0..b9a320192c 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -94,7 +94,7 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix. * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`. * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used. -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. diff --git a/content/en/docs/concepts/cluster-administration/federation.md b/content/en/docs/concepts/cluster-administration/federation.md index 7900b53d27..e26aef3fa8 100644 --- a/content/en/docs/concepts/cluster-administration/federation.md +++ b/content/en/docs/concepts/cluster-administration/federation.md @@ -140,7 +140,7 @@ Reasons to prefer fewer clusters per availability zone are: - improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation). - reduced operational overhead (though the advantage is diminished as ops tooling and processes mature). - - reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage + - reduced costs for per-cluster fixed resource costs, for example apiserver VMs (but small as a percentage of overall cluster cost for medium to large clusters). Reasons to have multiple clusters include: diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 2c1ab5f3fe..e464a2869e 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -76,7 +76,7 @@ should set up a solution to address that. For example, in Kubernetes clusters, deployed by the `kube-up.sh` script, there is a [`logrotate`](https://linux.die.net/man/8/logrotate) tool configured to run each hour. You can also set up a container runtime to -rotate application's logs automatically, e.g. by using Docker's `log-opt`. +rotate application's logs automatically, for example by using Docker's `log-opt`. In the `kube-up.sh` script, the latter approach is used for COS image on GCP, and the former approach is used in any other environment. In both cases, by default rotation is configured to take place when log file exceeds 10MB. diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 2c5becff54..19f33c47e8 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -17,7 +17,7 @@ There are several ways to do this, and the recommended approaches all use [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection. Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.) -but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure +but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different services that communicate a lot into the same availability zone. @@ -176,7 +176,7 @@ Y is expressed as a LabelSelector with an optional associated list of namespaces (and therefore the labels on pods are implicitly namespaced), a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the -key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above +key for the node label that the system uses to denote such a topology domain; for example, see the label keys listed above in the section [Interlude: built-in node labels](#built-in-node-labels). {{< note >}} @@ -366,7 +366,7 @@ Some of the limitations of using `nodeName` to select nodes are: some cases may be automatically deleted. - If the named node does not have the resources to accommodate the pod, the pod will fail and its reason will indicate why, - e.g. OutOfmemory or OutOfcpu. + for example OutOfmemory or OutOfcpu. - Node names in cloud environments are not always predictable or stable. diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 3cb5f3ffa8..a9b76cdd51 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -154,7 +154,7 @@ most network plugins. Where needed, you can specify the MTU explicitly with the `network-plugin-mtu` kubelet option. For example, on AWS the `eth0` MTU is typically 9001, so you might specify `--network-plugin-mtu=9001`. If you're using IPSEC you -might reduce it to allow for encapsulation overhead e.g. `--network-plugin-mtu=8873`. +might reduce it to allow for encapsulation overhead; for example: `--network-plugin-mtu=8873`. This option is provided to the network-plugin; currently **only kubenet supports `network-plugin-mtu`**. diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 89788349b8..5a55665db3 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -350,7 +350,7 @@ parameters: contains user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have - type `"kubernetes.io/glusterfs"`, e.g. created in this way: + type `"kubernetes.io/glusterfs"`, for example created in this way: ``` kubectl create secret generic heketi-secret \ @@ -514,7 +514,7 @@ parameters: same as `adminId`. * `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It must exist in the same namespace as PVCs. This parameter is required. - The provided secret must have type "kubernetes.io/rbd", e.g. created in this + The provided secret must have type "kubernetes.io/rbd", for example created in this way: ```shell @@ -561,7 +561,7 @@ parameters: * `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate against the API server. The provided secret must have type "kubernetes.io/quobyte" and the keys `user` and `password`, - e.g. created in this way: + for example: ```shell kubectl create secret generic quobyte-admin-secret \ diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 2ab54051a4..3d85194ed7 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -732,7 +732,7 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss ``` * It's worth reiterating that in 1.9, these happen in a mutating phase -and a validating phase, and that e.g. `ResourceQuota` runs in the validating +and a validating phase, and that for example `ResourceQuota` runs in the validating phase, and therefore is the last admission controller to run. `MutatingAdmissionWebhook` appears before it in this list, because it runs in the mutating phase. diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 4131a79df8..4da9bc951c 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -1050,7 +1050,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a mutating webhook configured to call a URL diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 776715c8a2..8c7464d694 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -578,7 +578,7 @@ A number of markers were added in Kubernetes 1.16 and 1.17, to allow API develop | Golang marker | OpenAPI extension | Accepted values | Description | Introduced in | |---|---|---|---|---| | `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16 | -| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 | +| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 | | `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 | | `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 | diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 2c978b0653..889b85f64d 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -403,7 +403,7 @@ for `kubeadm`. ### Control plane node isolation By default, your cluster will not schedule Pods on the control-plane node for security -reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a +reasons. If you want to be able to schedule Pods on the control-plane node, for example for a single-machine Kubernetes cluster for development, run: ```bash diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index caf20d7f2e..8b4480de2f 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -63,7 +63,7 @@ The jsonpath is interpreted as follows: - `.image`: get the image {{< note >}} -When fetching a single Pod by name, e.g. `kubectl get pod nginx`, +When fetching a single Pod by name, for example `kubectl get pod nginx`, the `.items[*]` portion of the path should be omitted because a single Pod is returned instead of a list of items. {{< /note >}} diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 9b5e997782..ecda7709cf 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -113,7 +113,7 @@ track=stable - **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials. - Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters. + Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters. In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied. diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md index f730fb3660..184e870fc3 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md @@ -502,7 +502,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a conversion webhook configured to call a URL diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index b2d5703b1c..dd96f2d6d6 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -366,7 +366,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables {{< feature-state state="stable" for_kubernetes_version="1.16" >}} -CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources like e.g. a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. +CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. {{< tabs name="CustomResourceDefinition_pruning" >}} {{% tab name="apiextensions.k8s.io/v1" %}} diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md index 3cce9c7153..bdc871ddd9 100644 --- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md +++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md @@ -37,7 +37,7 @@ The agent configuration file must be written in YAML or JSON syntax, and may con * **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges. * **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default. -* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc... +* **resyncInterval:** A time interval at which the agent attempts to reload config from disk. For example: '30s', where 's' means seconds, 'ms' means milliseconds, etc... Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent: diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index 9f341d046f..5e57c18379 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -72,9 +72,9 @@ cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be scheduled, but will fail to launch. With the warning above in mind, the cluster admin can allow certain _unsafe_ -sysctls for very special situations like e.g. high-performance or real-time +sysctls for very special situations such as high-performance or real-time application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a -flag of the kubelet, e.g.: +flag of the kubelet; for example: ```shell kubelet --allowed-unsafe-sysctls \ diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 320d800dc9..fc31526348 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -63,7 +63,7 @@ For example, this is how to start a simple web server as a static Pod: ssh my-node1 ``` -2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`: +2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`: ```shell # Run this command on the node where kubelet is running diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 4d0521722a..847d76f25c 100644 --- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -580,7 +580,7 @@ If you want to create normal pods without controllers you can use `restart` cons The controller object could be `deployment` or `replicationcontroller`, etc. {{< /note >}} -For e.g. `pival` service will become pod down here. This container calculated value of `pi`. +For example, the `pival` service will become pod down here. This container calculated value of `pi`. ```yaml version: '2' diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 2c769eb933..ed95d353ac 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -272,7 +272,7 @@ to turn up in a new cluster. The scheme must be "https"; the URL must begin with "https://". -Attempting to use a user or basic auth e.g. "user:password@" is not allowed. +Attempting to use a user or basic auth (for example "user:password@") is not allowed. Fragments ("#...") and query parameters ("?...") are also not allowed. Here is an example of a webhook configured to call a URL diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index 4e95d82905..ae56c42411 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -55,7 +55,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your - Network partition within cluster, or between cluster and users - Crashes in Kubernetes software - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) - - Operator error, e.g. misconfigured Kubernetes software or application software + - Operator error, for example misconfigured Kubernetes software or application software ### Specific scenarios: diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md index d075944516..a60ceeedfb 100644 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -362,7 +362,7 @@ you want to add Kafka sink for messages from a particular container for addition You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) with minor changes: -* Change Makefile to point to your container repository, e.g. `PREFIX=gcr.io/`. +* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/`. * Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`. Then run `make build push` from this directory. After updating `DaemonSet` to pick up the From 54162359577ad27d44815b21b7856bfadf45cd08 Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Sun, 1 Mar 2020 12:06:40 +0300 Subject: [PATCH 23/32] Translate Localizing Kubernetes Documentation page into Russian (#19173) --- content/ru/docs/contribute/localization.md | 286 +++++++++++++++++++++ 1 file changed, 286 insertions(+) create mode 100644 content/ru/docs/contribute/localization.md diff --git a/content/ru/docs/contribute/localization.md b/content/ru/docs/contribute/localization.md new file mode 100644 index 0000000000..4706ff4e90 --- /dev/null +++ b/content/ru/docs/contribute/localization.md @@ -0,0 +1,286 @@ +--- +title: Локализация документации Kubernetes +content_template: templates/concept +card: + name: contribute + weight: 30 + title: Перевод документации +--- + +{{% capture overview %}} + +На этой странице рассказывается, как [локализовать](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) документацию на разные языки. + +{{% /capture %}} + +{{% capture body %}} + +## Начало работы + +Из-за того, что участники не могут одобрять собственные пулреквесты, нужно как минимум два участника для инициализации локализацию. + +Все команды по локализации должны быть самодостаточными. Это означает, что мы с радостью разместим вашу работу, но мы не можем сделать перевод за вас. + +### Определение двухбуквенного кода языка + +Первым делом ознакомьтесь со [стандартом ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php), чтобы найти двухбуквенный код страны для вашей локализации. Например, двухбуквенный код для корейского языка будет `ko`. + +### Создание копии репозитория + +Для начала [создайте собственную копию репозитория](/ru/docs/contribute/start/#улучшение-существующего-текста) оригинального репозитория [kubernetes/website](https://github.com/kubernetes/website). + +Затем клонируйте свою копию репозитория и перейдите в неё с помощью команды `cd`: + +```shell +git clone https://github.com//website +cd website +``` + +### Создание пулреквеста + +Далее [откройте пулреквест](/ru/docs/contribute/start/#отправка-пулреквеста) (PR) с локализацией в репозиторий `kubernetes/website`. + +Для того, чтобы ваш пулреквест был одобрен, он должен содержать [необходимый минимум контента](#необходимый-минимум-контента). + +В качестве примера добавления новой локализации, изучите PR, который добавляет [документацию на французском](https://github.com/kubernetes/website/pull/12548). + +### Вступление в GitHub-организацию Kubernetes + +Как только, как вы открыли PR с локализацией, вы можете стать членом организации Kubernetes на GitHub. Каждый член команды должен подать [запрос на членство в организации](https://github.com/kubernetes/org/issues/new/choose) в репозитории `kubernetes/org`. + +### Добавление команды локализации на GitHub + +Теперь нужно добавить вашу команду локализации Kubernetes в файл [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). Для примера добавления команды локализации можете посмотреть PR, добавляющий [испанскую команду локализации](https://github.com/kubernetes/org/pull/685). + +Члены `@kubernetes/sig-docs-**-owners` — могут одобрять PR, которые изменяют файлы внутри (и только там) директории с локализацией: `/content/**/`. + +Для каждой локализации группа `@kubernetes/sig-docs-**-reviews` служит для автоматизации выбора проверяющих новых PR. + +Члены `@kubernetes/website-maintainers` могут создавать новые ветки для координации работ по переводу. + +Члены `@kubernetes/website-milestone-maintainers` могут использовать [Prow-команду](https://prow.k8s.io/command-help) `/milestone` для контрольных точек для ишью или PR. + +### Настройка рабочего процесса + +Затем добавьте собственную GitHub-метку для вашей локализации в репозиторий `kubernetes/test-infra`. Метка позволяет фильтровать ишью и пулреквесты по конкретному языку. + +Смотрите пример добавления [метки для итальянского языка](https://github.com/kubernetes/test-infra/pull/11316). + +### Поиск сообщества + +Сообщите участниками группы Kubernetes SIG Docs о вашем намерении перевода документации! Подключайтесь к [Slack-каналу SIG Docs](https://kubernetes.slack.com/messages/C1J0BPD2M/). Остальные команды по локализации с радостью помогут вам начать и ответят на любые вопросы. + +Вы также можете создать Slack-канал для своей локализации в репозитории `kubernetes/community`. Для примера посмотрите PR с [добавлением Slack-канала для индонезийского и португальского языков](https://github.com/kubernetes/community/pull/3605). + +## Необходимый минимум контента + +### Изменение конфигурации сайта + +Сайт Kubernetes использует использует фреймворк Hugo. Конфигурация сайта у Hugo находится в файле [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml). Для поддержки новой локализации вам нужно отредактировать файл `config.toml`. + +Добавьте блок с конфигурацией для нового языка в `config.toml` после существующего блока `[languages]`. Например, конфигурация для немецкой локализации будет выглядить так: + +```toml +[languages.de] +title = "Kubernetes" +description = "Produktionsreife Container-Verwaltung" +languageName = "Deutsch" +contentDir = "content/de" +weight = 3 +``` + +При выбора значения для параметра `weight` в блока найдите языковой блок с наибольшим значением и прибавьте к нему 1. + +Для получения дополнительной информации о многоязычной поддержке в Hugo посмотрите страницу "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". + +### Добавление директории для локализации + +Добавьте директорию для вашего языка в директорию [`content`](https://github.com/kubernetes/website/tree/master/content) репозитория. Например, двухбуквенный код для немецкого будет `de`: + +```shell +mkdir content/de +``` + +### Перевод норм поведения сообщества + +Откройте PR в репозитории [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) и добавьте перевод норм поведения на своём языке. + +### Добавление перевода для файла README + +Чтобы помочь другим участников локализации добавьте новый файл [`README-**.md`](https://help.github.com/articles/about-readmes/) в корневую директорию k/website, где `**` означает двухбуквенный код языка. Например, немецкий файл README будет именоваться как `README-de.md`. + +Подготовьте рекомендации для участников в файле для конкретной локализации `README-**.md`. В этом файле должна быть точно такая же информация, что и в оригинальном README.md ту же информацию, включая также: + +- Контактное лицо проекта локализации +- Любая другая информация, относящаяся к локализации + +После создания перевода файла README добавьте ссылку на файл в основной английский файл `README.md` и добавьте контактную информацию на английском языке. Вы можете указать логин на GitHub, адрес электронной почты, Slack-канал или какой-нибудь способ связи. Вам также нужно добавить ссылку на перевод норм поведения в сообществе. + +### Настройка файлов OWNERS + +Для определения роли каждого пользователя, участвующего в локализации, создайте файл `OWNERS` в директории языка, указав в нём следующие секции: + +- **reviewers**: список Kubernetes-команд с ролями рецензентов, в данном случае команда `sig-docs-**-reviews` будет создана в разделе [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github). +- **approvers**: список Kubernetes-команд с ролями утверждающих, в данном случае команда `sig-docs-**-owners` будет создана в разделе [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github). +- **labels**: список GitHub-меток, которые будут автоматически добавляться к PR, в данном случае метка языка будет создана в разделе [Настройка рабочего процесса](#настройка-рабочего-процесса). + +Дополнительную информацию о файле `OWNERS` вы можете получить по ссылке [go.k8s.io/owners](https://go.k8s.io/owners). + +[Испанский файл OWNERS](https://git.k8s.io/website/content/es/OWNERS) с кодом языка `es` выглядит следующим образом: + +```yaml +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the localization project for Spanish. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-es-reviews + +approvers: +- sig-docs-es-owners + +labels: +- language/es +``` + +После добавления файла `OWNERS` в определенном языке нужно обновить [корневой файл `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES), добавив новые команды локализации Kubernetes — `sig-docs-**-owners` и `sig-docs-**-reviews`. + +Для каждой команды добавьте список GitHub-пользователей из раздела [Добавление команды локализации на GitHub](#добавление-команды-локализации-на-github), перечислите их в алфавитном порядке. + +```diff +--- a/OWNERS_ALIASES ++++ b/OWNERS_ALIASES +@@ -48,6 +48,14 @@ aliases: + - stewart-yu + - xiangpengzhao + - zhangxiaoyu-zidif ++ sig-docs-es-owners: # Admins for Spanish content ++ - alexbrand ++ - raelga ++ sig-docs-es-reviews: # PR reviews for Spanish content ++ - alexbrand ++ - electrocucaracha ++ - glo-pena ++ - raelga + sig-docs-fr-owners: # Admins for French content + - perriea + - remyleone +``` + +## Перевод контента + +Локализация *всей* документации Kubernetes — колоссальная задача. Вполне нормально начать переводить что-то небольшое, а затем со временем делать перевод больших страниц. + +Как минимум, все локализации должны включать: + +Описание | URL-адреса +-----|----- +Главная | [Все заголовки и подзаголовки URL-адресов](/ru/docs/home/) +Установка | [Все заголовки и подзаголовки URL-адресов](/ru/docs/setup/) +Руководства | [Основы Kubernetes](/ru/docs/tutorials/kubernetes-basics/), [Привет, Minikube](/ru/docs/tutorials/stateless-application/hello-minikube/) +Надписи на сайте | [Все надписи сайта в собственном TOML-файле](https://github.com/kubernetes/website/tree/master/i18n) + +Переведенные файлы должны находиться в собственной директории `content/**/`, но в во всём остальном должны быть такие, как и оригинал на английском. Например, чтобы подготовить [Основы Kubernetes](/ru/docs/tutorials/kubernetes-basics/) для перевода на немецкий язык, создайте поддиректорию в директории `content/de/` и скопируйте туда оригинальный английский файл: + +```shell +mkdir -p content/de/docs/tutorials +cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md +``` + +С помощью соответствующих инструментов можно ускорить процесс перевода. Например, у некоторых редакторов есть плагины для быстрого перевода текста. + +{{< caution >}} +Использование только машинного перевода не будет соответствовать минимальному уровню качества и поэтому такой перевод требует тщательного ручного рассмотрения для соблюдения стандарта качества. +{{< /caution >}} + +To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing. + +### Исходные файлы + +Локализация должна исходить из самой последней версии оригинальной документации — {{< latest-version >}}. + +Для того, чтобы получить исходные файлы последней версии: + +1. Перейдите в репозиторий сайта Kubernetes по адресу https://github.com/kubernetes/website. +2. Выберите ветку `release-1.X` самой последней версии. + +Текущая последняя версия {{< latest-version >}}, поэтому веткой для этого релиза будет [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). + +### Сообщения на сайте в i18n/ + +Локализации должны включать содержимое файла [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) в новый языковой файл. В качестве примера рассмотрим немецкую локализацию: `i18n/de.toml`. + +Добавьте новый файл локализации в `i18n/`. Например, для немецкой локализации (`de`): + +```shell +cp i18n/en.toml i18n/de.toml +``` + +Затем переведите значение каждого сообщения: + +```TOML +[docs_label_i_am] +other = "ICH BIN..." +``` + +Локализация сообщений сайта позволяет изменить сообщения, используемые на всём сайте, к примеру, текст авторских прав в футере на каждой странице. + +### Глоссарий и руководство по оформления для языка + +У некоторых языковых команд есть собственные руководства по оформлению и глоссарий. Например, посмотрите [руководство корейской локализации](/ko/docs/contribute/localization_ko/). + +## Стратегия работы с ветками + +Работа в проектах локализации осуществляется посредством совместных усилий, поэтому мы приветствуем решение команды работать в общих ветках разработки. + +Совместная работа в рабочих ветках может быть организована следующим образом: + +1. Член команды [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) создает ветку из оригинальной ветки на https://github.com/kubernetes/website. + + После того, как вы [добавите свою команду локализации](#добавление-команды-локализации-на-github) в репозиторий [`kubernetes/org`](https://github.com/kubernetes/org), ваши утверждающие из группы будет присоединены к команде `@kubernetes/website-maintainers`. + + Мы рекомендуем следующую схему именования веток: + + `dev-<оригинальная версия>-<код языка>.<контрольная точка команды>` + + Например, утверждающий в немецкой группе локализации открывает рабочую ветку `dev-1.12-de.1` непосредственно в репозитории kubernetes/website из ветки для Kubernetes v1.12. + +2. Остальные участники создают новые ветки с изменениями на основе рабочей ветки. + + Например, участник немецкой группы локализации открывает пулреквест с изменениями в `kubernetes:dev-1.12-de.1` из `username:local-branch-name`. + +3. Утверждающий проверяет изменения и объединяют ветки в рабочую веткой. + +4. Периодически утверждающий объединяет рабочую ветку в оригинальную ветку, открывая и принимая новый пулреквест. Не забудьте объединить (squash) коммиты перед слиянием пулреквеста. + +Повторяйте шаги 1-4 до тех пор, пока не будет завершена локализация. Например, по мере работы над немецким переводом, рабочие ветки будут меняться: `dev-1.12-de.2`, `dev-1.12-de.3` и т.д. + +Команды должны объединять переведённый контент в ту же ветку выпуска, из которой она была создана. Например, рабочая ветка, созданная из версии {{< release-branch >}}, должна сливаться с веткой версии 1.17. + +Утверждающему следует поддерживать рабочую веку в актуальном состоянии в соответствии с оригинальной веткой, разрешая конфликты при слиянии. Чем дольше существует рабочая ветки, тем больше потребуется сил для ее поддержки. Поэтому лучше как можно быстрее сливать рабочую ветку и открывать новую, а не поддерживать только одну-единственную в течение длительного времени. + +В начале каждой контрольной точки команды полезно открыть ишью для сравнения изменений между предыдущей веткой и текущей рабочей веткой. + +Хотя только утверждающие могут открывать новую рабочую ветку и сливать пулреквесты, но любой может открыть пулреквест с новой веткой, которая может быть рабочей для команды. Никаких специальных разрешений для этого не требуется. + +Для получения дополнительной информации о работе с копиями или непосредственно с оригинальным репозиторией смотрите раздел по [созданию и клонированию копии репозитория](#создание-копии-репозитория). + +## Участие в работе над оригинальным контентом + +SIG Docs приветствует [участие и дополнения](/ru/docs/contribute/intermediate#локализация-контента) в английскую документацию. + +## Помощь для существующей локализации + +Вы также можете добавлять или улучшать контент в уже существующей локализации. Обратитесь к соответствующему [Slack-каналу](https://kubernetes.slack.com/messages/C1J0BPD2M/) для этого и начинайте помогать через PR. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Как только локализация будет соответствовать требованиям установленного рабочего процесса и содержать требуемый минимум контента, группа SIG Docs: + +- Добавит язык на сайт +- Сообщит о новой локализации на каналах [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), включая [блог Kubernetes](https://kubernetes.io/blog/). + +{{% /capture %}} From 006643f9d6745cfc4cd3ef8c8e5c1a06431c754d Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Sun, 1 Mar 2020 12:12:41 +0300 Subject: [PATCH 24/32] Translate Intermediate contributing page into Russian (#19215) --- content/ru/docs/contribute/intermediate.md | 606 +++++++++++++++++++++ 1 file changed, 606 insertions(+) create mode 100644 content/ru/docs/contribute/intermediate.md diff --git a/content/ru/docs/contribute/intermediate.md b/content/ru/docs/contribute/intermediate.md new file mode 100644 index 0000000000..2658dc3500 --- /dev/null +++ b/content/ru/docs/contribute/intermediate.md @@ -0,0 +1,606 @@ +--- +title: Участие для продолжающих +slug: intermediate +content_template: templates/concept +weight: 20 +card: + name: contribute + weight: 50 +---1 + +{{% capture overview %}} + +На этой странице предполагается, что вы изучили и понимаете задачи на странице [Начало участия](/ru/docs/contribute/start/) и теперь готовы узнать о других способах внести свой вклад. + +{{< note >}} +Некоторые задачи требуют использование Git-клиента из командной строки и других инструментов. +{{< /note >}} + +{{% /capture %}} + +{{% capture body %}} + +Теперь, когда вы уже знаете кое-что и приняли участие в документации Kubernetes, как описано в теме [Начало участия](/ru/docs/contribute/start/), вы можете пойти ещё дальше. Далее пойдут задачи, предусматривающие наличие и желание получить глубокие знания по следующим темам: + +- Концепции Kubernetes +- Рабочие процессы документации Kubernetes +- Поиск нужной информации о будущих возможностях Kubernetes +- Сильные аналитические навыки в целом + +Эти задачи не такие последовательные, как задачи для начинающих. Поэтому мы не ожидаем, что кто-то в одиночку будет постоянно заниматься всеми ими. + +## Знакомство с Prow + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) — это система CI/CD, использующая Kubernetes, которая выполняет задания с пулреквестами (PR). Prow с помощью команд, похожих на те, что есть в чатботах, даёт возможность обрабатывать действия в организации Kubernetes на GitHub. Вы можете выполнять целый ряд действий, такие как добавление и удаление меток, закрытие заявок и назначение утверждающего. Введите Prow-команду в поле для комментария в формате `/`. Некоторые популярные команды: + +- `/lgtm` (looks good to me): добавляет метку `lgtm`, которая сообщает, что рецензент проверил PR +- `/approve`: одобряет PR так, чтобы он мог быть принят (эта команда работает только для утверждающих) +- `/assign`: назначает проверяющего на PR +- `/close`: закрывает ишью или PR +- `/hold`: добавляет метку `do-not-merge/hold`, которая означает, что PR не может быть автоматически принят +- `/hold cancel`: удаляет метку `do-not-merge/hold` + +{{% note %}} +Не все команды работают для каждого пользователя. Бот Prow сообщит вам, если вы пытаетесь выполнить команду, не разрешенную для вашего уровня. +{{% /note %}} + +Детально изучите [список команд Prow](https://prow.k8s.io/command-help), прежде чем начать проверять PR или сортировать ишью. + +## Проверка пулреквестов + +Каждую неделю утверждающий доброволец документации сортирует и просматривает [пулреквесты и заявки](#сортировка-и-классификация-ишью). Такой человек называется "PR Wrangler" на неделю. Расписание ведется с помощью [планировщика PR Wrangler](https://github.com/kubernetes/website/wiki/PR-Wranglers). Чтобы поучаствовать в этом списке, посетите еженедельную встречу SIG Docs. Даже если вас не выбрали дежурным по PR на текущую неделю, вы все равно можете проверять пулреквесты (PR), которые еще не были детально просмотрены. + +В дополнение к ротации автоматизированная система добавляет в каждый новый PR и предлагает рецензентов и утверждающих для него, основываясь на списке утверждающих и рецензентов в измененных файлах. Ожидается, что автор PR будет следовать указаниям бота, поэтому PR должен быть быстро проверить. + +Мы хотим, чтобы пулреквесты принимались и публиковались как можно быстрее. Чтобы документация оставалась точной и актуальной, каждый PR должен проверяться людьми, понимающие суть темы, а также теми, кто имеет опыт написания отличной документации. + +Рецензенты и утверждающие должны предоставить конкретную и конструктивную обратную связь, чтобы заинтересованные участники были вовлечены и помогали им улучшаться. Иногда, чтобы помочь новому участнику подготовить свой PR к слиянию, требуется больше времени, чем просто переписать его самостоятельно, но проект лучше в долгосрочной перспективе, когда у нас есть множество активных участников. + +Прежде чем приступить к проверке PR, убедитесь, что вы знакомы с [руководством по содержанию документации](/docs/contribute/style/content-guide/), [руководством по оформлению документации](/docs/contribute/style/style-guide/) и [нормы поведения](/community/code-of-conduct/). + +### Поиск пулреквестов для проверки + +Чтобы посмотреть все открытые пулреквесты, перейдите на вкладку **Pull Requests** в GitHub-репозитории. +PR можно проверять только, если он соответствует всем перечисленным ниже критериям: + +- Имеет метку `cncf-cla:yes` +- Не содержит надписи WIP в описании +- Не имеет тег с фразой `do-not-merge` +- Нет конфликтов для слияния +- Сделан в правильную ветку (обычно это `master`, за исключением, если PR не относится к невыпущенной ещё функциональности) +- Не проверялся ещё детально другим проверяющим документации (то же самое касается и остальных технических рецензентов), если только этот человек явно не обратился за вашей помощью. В частности, не рекомендуется добавлять много новых комментариев после других циклов рассмотрения PR. + +Если PR не имеет условия для проверки, можно оставить комментарий, чтобы сообщить автору о текущих проблемах и предложить помочь решить их. Если автор пулреквеста был оповещён о проблемах и не устранил их в течение нескольких недель или месяцев, то рано или поздно такой PR будет закрыт. + +Если вы новичок в проверке пулреквестов или у вас недостаточно времени и возможностей, попробуйте поискать PR с тегом `size/XS` или `size/S`. Размер пулреквеста автоматически определяется по количеству изменённых строк в PR. + +#### Рецензенты и утверждающие + +В репозитории сайта Kubernetes работа построена иначе, чем в других репозиториях Kubernetes, когда речь идет о роли рецензентов и утверждающих. Для получения дополнительной информации об обязанностях рецензентов и утверждающих см. [Участие в SIG Docs](/ru/docs/contribute/participating/). Ниже вы найдете краткий обзор. + +- Рецензент проверяет содержание пулреквеста для соблюдения технической точности. Рецензент даёт понять, что PR технически точен, оставляя комментарий с `/lgtm` к PR. + + {{< note >}}Не добавляйте `/lgtm`, если вы не уверены в технической точности документации, измененной или добавленной в PR.{{< /note >}} + +- Утверждающий проверяет содержание запроса на предмет качества и соответствия рекомендациям SIG Docs, приведенным в руководствах по содержанию и оформлению. Только люди, указанные в качестве утверждающих в файле [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS), могут одобрить PR. Чтобы одобрить PR, оставьте комментарий `/approve` к PR. + +PR объединяется, когда у него есть комментарий `/lgtm` от кого-либо из организации Kubernetes и комментарий `/approve` от утверждающего в группе `sig-docs-maintainers`, если он не удерживается, а автор PR подписал CLA. + +{{< note >}} + +Раздел ["Участие"](/ru/docs/contribute/participating/#утверждающие) содержит больше информации для рецензентов и утверждающих, включая конкретные обязанности для утверждающих. + +{{< /note >}} + +### Проверка PR + +1. Изучите описание PR вместе с указанными ишью и ссылками, если они есть. Кратковременные мимолетные обзоры иногда могут наносит больше вреда, чем пользы, поэтому убедитесь, что вы обладаете нужными знаниями, чтобы сделать содержательный обзор. + +2. Если кто-то другой может лучше всего проверит определенный PR, упомяните этого человека, добавив комментарий `/assign @`. Если вы обратились за технической проверкой к человеку, который не занимается документацией, но при этом вы хотите сами посмотреть PR как участник группы документации, то не стесняйтесь это делать. + +3. Перейдите на вкладку **Files changed**. Посмотрите на все изменённые строки. Удалённый текст выделен красным, а строки с ним начинаются с символа `-`. Добавленный текст отмечен зелёным фоном, а строки с ним начинаются с символа `+`. Внутри строки фактически измененный контент имеет чуть более темный зеленый фон, чем остальная часть строки. + + - В частности, если в PR есть сложное форматирование или он изменяет CSS, JavaScript или другие элементы сайта, вы можете просмотреть сайт, сгенерированный с этими изменениями в PR. Перейдите на вкладку **Conversation** и нажмите ссылку **Details** в проверке `deploy/netlify` в нижней части страницы. По умолчанию ссылка открывается в текущей вкладке браузера, поэтому чтобы потерять частичный отзыв, откройте ссылку в новой вкладке. Вернитесь на вкладку **Files changed**, чтобы продолжить проверку пулреквеста. + - Убедитесь, что PR соответствует правилам содержания и оформления; если что-то не так, укажите на этом со ссылкой на раздел в руководстве. + - Если у вас есть вопрос или вы хотите прокомментировать определённое изменение, наведите курсор мыши на строку и кликните на появившуюся сине-белую кнопку с иконкой `+`. Напишите свой комментарий и нажмите на кнопку **Start a review**. + - Если вам нужно оставить больше одного комментария, сделайте это по аналогии с предыдущим шагом. + - По соглашению, если вы видите небольшую проблему, не имеющей отношение к основному назначению PR, например, опечатку или лишний пробел, вы можете сообщить о ней, начав комментарий с `nit:`, чтобы автор знал, что это незначительная ошибка. Хотя это не означает, что автор пулреквеста может проигнорировать такие проблемы. + - Когда вы всё проверили или у вас не осталось комментариев, прокрутите в верхнюю часть страницы и нажмите на кнопку **Review changes**. Далее кликните либо на **Comment** или **Request Changes**. Напишите краткий итог вашей проверки и добавьте соответствующие [Prow-команды](https://prow.k8s.io/command-help) по одной на каждой строке в поле Review Summary. SIG Docs следует [процессу проверки кода Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). Все ваши комментарии будут отправлены автору PR в виде одного уведомления. + + - Если вы считаете, что PR в хорошем состоянии, чтобы его принять, добавьте команду `/approve` в резюме вашей проверки. + - Если PR не нуждается в дополнительном техническом рассмотрении, добавьте ещё команду `/lgtm`. + - Если PR *требуется* дополнительный технический обзор, добавьте команду `/assign` и после неё укажите логин человека на GitHub, который должен сделать технический анализ. Посмотрите на поле рецензентов во вступительной (фронтальной) части вверху данного Markdown-файла, чтобы выяснить, кто может провести технический разбор пулреквеста. + - Чтобы заблокировать слияние PR, используйте команду `/hold`. Она добавит метку `do-not-merge/hold`. + - Если в PR нет конфликтов и есть метки `lgtm` и `approve` (и нет метки `hold`), то он автоматически объединиться. + - Если PR имеет метки `lgtm` и/или `approve`, и появляются новые изменения, эти метки будут автоматически удалены. + + Посмотрите [список доступных команд](https://prow.k8s.io/command-help), которые можно использовать в PR. + + - Если вы ранее выбрали нажали на **Request changes** и затем автор PR решил все указанные проблемы, вы можете обновить статус проверки либо на вкладке **Files changed**, либо в нижней части вкладки **Conversation**. Обязательно укажите команду `/approve` и при необходимости выберите технических рецензентов, чтобы можно было объединить PR. + +### Редактирование PR другого человека + +Добавление комментариев в PR — полезное дело, но могут быть случаи, когда нужно сделать коммит в пулреквест другого человека, а не просто оставить свой отзыв. + +Не поддавайтесь желанию выполнить работу за другого человека, если только он явно не попросит вас об этом или вы не захотите оживить давно заброшенный PR. Хотя это может быть быстрее в краткосрочной плане, но это лишает человека возможности внести собственный вклад. + +Используемый процесс зависит от того, нужно ли вам отредактировать файл, который уже изменен в PR, либо вам нужно отредактировать файл, который в PR не участвовал. + +Вы не можете отредактировать чужой PR, если выполняется одно из условий: + +- Если автор PR отправил свою ветку непосредственно в репозиторий [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/), то только рецензент с правом отправки изменений напрямую в репозиторий может вносить изменения в PR. + Авторам следует открыть PR из ветки в своей копии репозитория. +- Если автор PR явно запретил редактирование утверждающими, вы не сможете внести изменения в его PR, пока он не изменит эту настройку. + +#### Если файл уже изменён в PR + +Этот метод использует интерфейс GitHub. Вы можете использовать командную строку, если вам комфортнее работать в ней, даже если вам нужно изменить файл, который ранее редактировался в PR. + +1. Перейдите на вкладку **Files changed**. +2. Прокрутите к блоку с файлом, который вы хотите отредактировать и нажмите на иконку с карандашом. +3. Внесите изменения, напишите сообщение коммита в соответствующем поле под текстовым редактором и нажмите **Commit changes**. + +После этого ваш коммит отправляется в ветку из PR (скорее всего, в копию репозитория автора), и теперь отображается в PR, а ваши изменения отражаются на вкладке **Files changed**. Оставьте комментарий, чтобы автор PR знал, что вы что-то сделали в PR. + +Если автор использует командную строку, а не сайт GitHub для работы с этим PR, он должен получить изменения со своей копии репозитория и перебазировать свою локальную ветку на ветку своей копии, прежде чем заниматься своим PR. + +#### Если файл ещё не был изменён в PR + +Если необходимо внести изменения в файл, который не был отредактирован в рамках конкретного PR, нужно использовать командную строку. Вам придётся по душе такой метод, если вы предпочитаете использовать терминал вместо использования сайта GitHub. + +1. Узнайте URL-адрес копии репозитория автора пулреквеста. Вы можете найти его в нижней части вкладки **Conversation**. Найдите текст **Add more commits by pushing to**. Первая ссылка после этой надписи ведет на ветку, а вторая ссылка — на саму копию репозитория. Скопируйте вторую ссылку. Запомните название ветки, пригодится впоследствии. + +2. Добавьте копию репозитория как новый удаленный репозиторий. В терминале перейдите в директорию своей копии репозитория. Придумайте имя для удаленного репозитория (например, по имени логина автора на GitHub) и добавьте его, используя следующую команду: + + ```bash + git remote add + ``` + +3. Получите информацию о добавленном удаленном репозитории. Это действие не затронет локальные файлы, а только загрузит в вашу копии репозитория информацию о другой копии (например, ветки и теги). + + ```bash + git remote fetch + ``` + +4. Перейдите в ветку, полученную с удаленного репозитория. Эта команда не получится, если у вас локально уже есть ветка с таким же именем. + + ```bash + git checkout + ``` + +5. Внесите изменения и добавьте их через `git add`, а затем зафиксируйте их. + +6. Отправьте изменения в удаленный репозиторий автора. + + ```bash + git push + ``` + +7. Откройте снова сайт GitHub и обновите страницу PR. Вы увидите ваши изменения. Добавьте комментарий для автора, чтобы он был в курсе, что вы изменили его PR. + +Если автор использует командную строку, а не интерфейс на GitHub для работы над PR, ему нужно получить новые изменения из своей копии репозитоии и перебазировать свою локальную ветку на ветку своей копии репозитории, прежде чем снова заниматься собственным PR. + +## Работа из локальной копии + +В случае изменений нескольких файлов, либо добавлением новых или перемещением старых, лучше работать из локальной копии Git-репозитория на компьютере, нежели чем использовать для этого GitHub. Следующие инструкции используют командую утилиту `git`, которая предполагается, что она уже установлена на вашем компьютере. Вы можете воспользоваться ими даже, если пользуетесь графическим Git-клиента. + +### Клонирование репозитория + +Вам нужно только один раз клонировать репозиторий на каждом компьютере, на котором вы работаете с документацией Kubernetes. + +1. Создайте копию репозитория `kubernetes/website` на GitHub. В браузере перейдите по [https://github.com/kubernetes/website](https://github.com/kubernetes/website) и нажмите на кнопку **Fork**. После нескольких секунд вы будете автоматически перенаправлены на URL-адрес вашей копии, которая будет иметь следующий вид: `https://github.com//website`. + +2. В окне термина используйте команду `git clone` для получения копии репозитория. + + ```bash + git clone git@github.com//website + ``` + + После выполнения этой команды в текущей рабочей директории появится новая директория `website` с содержимым вашего репозитория на GitHub. В данном случае удаленный репозиторий `origin` будет ссылаться на вашу копию репозитория. + +3. Перейдите в новую директорию `website`. Добавьте новый удалённый репозиторий `kubernetes/website` под именем `upstream`. + + ```bash + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` + +4. Проверьте ваши репозитории `origin` и `upstream`. + + ```bash + git remote -v + ``` + + Output is similar to: + + ```bash + origin git@github.com:/website.git (fetch) + origin git@github.com:/website.git (push) + upstream https://github.com/kubernetes/website (fetch) + upstream https://github.com/kubernetes/website (push) + ``` + +### Работа в локальном репозитории + +Прежде чем начать работать в локальном репозитории, вам нужно выяснить, из какой ветки будет основываться ваша работа. Ответ на этот вопрос зависит от того, что хотите сделать, но можно руководствоваться следующими правилами: + +- Для общих улучшений существующего контента создайте собственную ветку от ветки `master`. +- Для добавления нового контента про функциональность, которая уже есть в текущих версиях Kubernetes, начните с ветки `master`. +- В случае большой и длительной работы, над которой будут трудиться несколько участников SIG Docs, например, реорганизация контента, создайте отдельную ветку, специально предназначенной для этого. +- Для нового контента про будущие, но ещё не выпущенные версии Kubernetes, работайте в ветке предварительного выпуска, созданной специально для этой версии Kubernetes. + +Для получения дополнительной информации обратитесь к разделу [Выбор правильной ветки](/ru/docs/contribute/start/#выбор-правильной-ветки-в-git). + +После того, как вы определили, с какой ветви начать свою работу (или на какой ветке будет _базироваться_ ваша работа, если говорить в терминологии Git), следуйте определённому ниже рабочему процессу, чтобы ваша работа оставалась актуальной. + +1. Когда вы работаете локально, есть три разные копии репозитория: `local`, `upstream` и `origin`. Получите данные по удалённым репозиториям `origin` и `upstream`. Эта команда очистит кеш удаленных репозиториях без фактического изменения каких-либо из копии. + + ```bash + git fetch origin + git fetch upstream + ``` + + Этот рабочий процесс отличается от того, который определен в [сообществе GitHub](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). Здесь вам не нужно объединять вашу локальную копию `master` из репозитория `upstream/master`, прежде чем отправлять изменения в вашу копию. Этот шаг не требуется в `kubernetes/website`, потому что ваша ветка базируется на репозитории upstream. + +2. Создайте локальную рабочую ветку из наиболее подходящей ветки upstream-репозитория: `upstream/dev-1.xx` для разработчиков в конкретных версиях или `upstream/master` для всех остальных участников. В этом примере предполагается, что вы будете работать с ветки `upstream/master`. Так как ваша локальная ветка `master` не настроена для отслеживания изменений с `upstream/master` на предыдущем шаге, поэтому вам нужно явно создать свою ветку от `upstream/master`. + + ```bash + git checkout -b upstream/master + ``` + +3. После переключения на новую ветку можно начать в ней работать в текстовом редакторе. Используйте команду `git status` , чтобы посмотреть измененные файлы. + +4. Когда вы закончите работу, зафиксируйте изменения. Сначала выполните команду `git status`, чтобы увидеть, какие изменения будут добавлены в коммит. В выводе этой команды есть две важные секции: `Changes staged for commit` и `Changes not staged for commit`. Файлы в последней секции, рядом с которыми есть надпись `modified` или `untracked`, необходимо добавить, если вы хотите, чтобы они попали в коммит. Для каждого файла, который нужно добавить, используйте команду `git add`. + + ```bash + git add example-file.md + ``` + + Когда все изменённые файлы добавлены, зафиксируйте их с помощью команды `git commit`: + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + В сообщении коммита не указывайте идентификатор или URL-адрес ишью или пулреквеста на GitHub. Если вы это сделаете, на странице ишью или пулреквеста будет показана информация о коммите всякий раз, когда коммит будет появляться в новой Git-ветке. Вы можете сослаться на ишью и пулреквесты позже на сайте GitHub. + {{< /note >}} + +5. При желании вы можете посмотреть, как ваши изменения будут выглядеть на сайте, если запустите сайт на вашей машине с помощью команды `hugo`. Посмотрите раздел [Просмотр ваших изменений локально](#просмотр-изменений-локально). Кроме этого, вы увидите свои изменения после создания пулреквеста. + +6. Перед тем, как открывать пулреквест с вашими изменениями вам для начала отправить в ветку удаленного репозитория, чем в данном случае является `origin`. + + ```bash + git push origin + ``` + + Технически вы можете не указать имя ветки в команде `push`, но корректное выполнение команды в таком случае зависит от используемой версии Git. Результаты будут более ожидаемыми, если вы напишите название ветки. + +7. Перейдите по адресу https://github.com/kubernetes/website в вашем браузере. GitHub определит и укажет вам, что вы загрузили новую ветку в свою копию, и поэтому предложит создать пулреквест. Заполните шаблон запроса. + + - Название должно быть не длиннее 50 символов и отражать краткий итог изменений. + - Подробное описание должно содержать больше информации про исправление, включая строку типа `Fixes #12345`, если пулреквест решает проблему на GitHub. Это приведет к автоматическому закрытию указанной ишью после принятия пулреквеста. + - Вы можете добавить метки или другие метаданные и назначить рецензентов. Смотрите страницу [Сортировка и классификация ишью](#сортировка-и-классификация-ишью). + + Нажмите на кнопку **Create pull request**. + +8. Начнут выполняться автоматические тесты в зависимости от состояния сайта с вашими изменениями. Если какой-либо из тестов завершился неудачно, нажмите на ссылку **Details** для получения дополнительной информации. Если тест Netlify прошёл успешно, по ссылке **Details** вы можете найти предварительную версию сайта Kubernetes с внесенными вашими изменениями. Именно на ней рецензенты будут проверять ваши изменения. + +9. Если вам необходимо что-то дополнить, изменить пулреквест в соответствии с выполненной проверкой, либо изменить текст коммита, вы можете использовать команду ниже. + + ```bash + git commit -a --amend + ``` + + - `-a`: зафиксировать все изменения + - `--amend`: изменить предыдущий коммит вместо создания нового + + Откроется текстовый редактор, чтобы вы могли отредактировать сообщение коммита, если это нужно. + + Если вы используете `git commit -m`, как в шаге 4, вы сделаете новый коммит, а не измените исходный (предыдущий) коммит. Создание нового коммита означает, что вам нужно объединить свои коммиты до того, прежде чем пулреквест может быть объединен. + + Следуйте инструкциям в шаге 6, чтобы отправить новый коммит в удаленный репозиторий. После этого новое изменение отобразится в пулреквесте, а дальше снова запустятся тесты, а также произойдет новая сборка предварительной версии сайта на Netlify с последними изменениями. + +10. Если рецензент изменяет файлы в вашем пулреквесте, вам нужно получить новые изменения в вашей локальной копии, до того как снова начать что-то делать. Используйте команды ниже, чтобы обновить свою ветку (предполагается, что ветка уже получена с вашей копии репозитория). + + ```bash + git fetch origin + git rebase origin/ + ``` + + После перебазирования вам нужно добавить флаг `--force-with-lease`, чтобы принудительно отправить новые изменения в ветке на вашу копию. + + ```bash + git push --force-with-lease origin + ``` + +11. Может возникнуть конфликт, если кто-то, как и вы, изменил те же части файла в ветке, из которой была создана ваша ветка. Если пулреквест показывает, что есть конфликты, которые нужно разрешить, вы можете сделать это либо на сайте GitHub, либо исправить их локально. + + Сначала выполните шаг 10, чтобы актуализировать локальную ветку в соответствии с веткой в удаленном репозитории. + + Затем обновите репозиторий `upstream` и перебазируйте вашу ветку на ту, с которой она была создана, в данном случае это `upstream/master`. + + ```bash + git fetch upstream + git rebase upstream/master + ``` + + Если есть конфликты, которые Git не может разрешить автоматически, вы можете увидеть конфликтующие файлы с помощью команды `git status`. Отредактируйте каждый конфликтующий файл: найдите в них маркеры конфликта `>>>`, `<<<` и `===`. Разрешение конфликта происходит путём удаления указанных маркеров конфликта. После это нужно добавить измененные файлы с помощью команды `git add ` и продолжить перебазирование ветки, используя команду `git rebase --continue`. Когда всё зафиксировано в репозитории и не осталось неразрешенных конфликтов, команда `git status` покажет, что вы вышли из состояния перебазирования ветки и нет изменений для фиксации. На этом этапе вам осталось принудительно отправить ветку в свою копию репозитория, после чего на странице пулреквеста не должны быть конфликты. + +12. Если у вашего PR отображаются несколько сделанных коммитов после редактирования предыдущих коммитов, вам следует объединить эти несколько коммитов в один коммит, чтобы PR мог быть объединен. Проверить количество коммитов можно на вкладке `Commits` на странице PR или выполнив `git log` в терминале. Объединение коммитов (Squashing commits) — это одна из форм перебазирования. + + ```bash + git rebase -i HEAD~ + ``` + + Ключ `-i` сообщает git, что вы хотите сделать перебазирование в интерактивном режиме. В этом режиме вы сможете выбрать для git, какие коммиты нужно объединить в один. Например, в вашей ветке есть 3 коммита: + + ``` + 12345 commit 4 (2 minutes ago) + 6789d commit 3 (30 minutes ago) + 456df commit 2 (1 day ago) + ``` + + Вам нужно объединить свои последние три коммита в один-единственный. + + ``` + git rebase -i HEAD~3 + ``` + + Эта команда откроет редактор с таким содержимым: + + ``` + pick 456df commit 2 + pick 6789d commit 3 + pick 12345 commit 4 + ``` + + Измените `pick` на `squash` у тех коммитов, которые вы хотите объединить, и проверьте, что коммит с выбранным `pick` находится сверху. + + ``` + pick 456df commit 2 + squash 6789d commit 3 + squash 12345 commit 4 + ``` + + Сохраните и закройте редактор. Затем отправьте объединённый коммит в репозитории с помощью команды `git push --force-with-lease origin `. + +Если у вас возникли проблемы с разрешением конфликтов или вы долго не можете что-то разрешить, что связано с вашим пулреквестом, обратитесь за помощью в Slack-канал `#sig-docs` или в [список рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +### Просмотр изменений локально + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="Hugo в контейнере" %}} + +Если вы ещё не готовы создать пулреквесты, но при этом хотите посмотреть, как будет выглядеть сайт с вашими изменениями, то можете собрать и запустить образ Docker, чтобы сгенерировать всю документацию и открыть ее на своем компьютере. + +1. Соберите образ локально: + + ```bash + make docker-image + ``` + +2. После того. как образ `kubernetes-hugo` собран, вы можете использовать его для запуска сайта: + + ```bash + make docker-serve + ``` + +3. В адресной строке браузера введите вставьте адрес `localhost:1313`. Hugo будет следить за изменениями файловой системы и пересобирать сайт по мере необходимости. + +4. Чтобы остановить локальный сайт Hugo, откройте снова терминал и введите `Ctrl+C` или просто закройте окно с терминалом. + +{{% /tab %}} +{{% tab name="Hugo на локальном компьютере" %}} + +1. Установите версию [Hugo](https://gohugo.io/getting-started/installing/), которая указана в файле [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). + +2. В терминале перейдите в корневую директорию вашей копии документации Kubernetes и введите следующую команду: + + ```bash + hugo server + ``` + +3. В адресной строке браузера скопируйте `localhost:1313`. + +4. Чтобы остановить локальный сайт Hugo, откройте снова терминал и введите `Ctrl+C` или просто закройте окно с терминалом. +{{% /tab %}} +{{< /tabs >}} + +## Сортировка и классификация ишью + +Люди в SIG Docs отвечают только за сортировку и классификацию ишью, связанных с документацией. Вопросы и проблемы общего характера также хранятся в репозитории `kubernetes/website`. + +Что вы делаете, когда сортируете ишью: + +- Проверить ишью + - Убедитесь, что ишью связана с документацией сайта. Некоторые заявки можно быстро закрыть, ответив на вопрос или указав автору на ресурс. Подробности смотрите в разделе [Заявки с помощью или отчёты об ошибке в коде](#заявки-с-помощью-или-отчёты-об-ошибке-в-коде). + - Рассмотрите, насколько обоснованной является заявка. Добавьте метку `triage/needs-information`, если в ишью описано мало подробностей, чтобы ее можно было начать решать, либо если шаблон был неправильно заполнен. + Закройте заявку, если она имеет метки `lifecycle/stale` и `triage/needs-information`. +- Добавьте метку с приоритетом (см. [руководство по сортировке заявок](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), где подробно определены метки) + - `priority/critical-urgent` - заниматься нужно прямо сейчас + - `priority/important-soon` - нужно выполнить в течение 3 months + - `priority/important-longterm` - нужно сделать в течение 6 months + - `priority/backlog` - решение можно быть отложено на неопределенный срок indefinitely; самый низкий приоритет; делать, когда будут свободны ресурсы + - `priority/awaiting-more-evidence` - указание, что это возможно хорошая задача, которую нужно иметь на виду +- Дополнительно вы можете добавить метку `help` или `good first issue`, если определенная заявка может быть решена человеком, мало знакомым с Kubernetes или SIG Docs. В качестве руководства обратитесь к файлу [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md). +- При желании примите сами участие в ишью и отправьте PR для ее решения (в частности если она может быстро разрешена или вы ранее выполняли нечто подобное). + +С помощью [этого фильтра](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) можно найти заявки, которые необходимо отсортировать. + +Если у вас есть вопросы о про сортировку, спросите в Slack-канале `#sig-docs` или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +### Добавление и удаление меток + +Для добавления метки нужен комментарий, содержащий что-то вроде `/` или `/ `. Метка уже должна быть создана в репозитории. Если вы попытаетесь добавить несуществующую метку, команда проигнорируется. + +Примеры: + +- `/triage needs-information` +- `/priority important-soon` +- `/language ja` +- `/help` +- `/good-first-issue` +- `/lifecycle frozen` + +Для удаления метки нужен комментарий с `/remove-` или `/remove- `. + +Примеры: + +- `/remove-triage needs-information` +- `/remove-priority important-soon` +- `/remove-language ja` +- `/remove-help` +- `/remove-good-first-issue` +- `/remove-lifecycle frozen` + +Список всех меток, используемых в Kubernetes, находится [здесь](https://github.com/kubernetes/kubernetes/labels). Не все метки используются группой SIG Docs. + +### Дополнительные сведения о метках + +- Ишью может иметь несколько ярлыков. +- Некоторые метки в своём имени содержат слеш для группировки, это своего рода "подметки". Например, существует множество меток `sig/`, например, `sig/cli` и `sig/api-machinery` ([полный список](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=sig%2F)). +- Некоторые метки добавляются автоматически, в зависимости от метаданных файлов из ишью, либо от используемых в комментариях команд со слешем, а также от указанной информации в описании. +- Новые метки могут добавляться вручную человеком, который сортировкой ишью (либо тем, кто создает ишью). + - `kind/bug`, `kind/feature` и `kind/documentation`: баг (bug) — это проблема в текущем контенте или в функциональности, а возможность (feature) — запрос на добавление нового контента или функциональности. + Метка `kind/documentation` используется редко. + - Метки `language/ja`, `language/ko` и похожие [языковые метки](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=language) добавляются, если ишью относится к локализованному контенту. + +### Жизненный цикл ишью + +Ишью обычно открываются и закрываются в течение относительно короткого промежутка времени. Однако иногда решение заявки после ее создания может и не быть. Иногда ишью может оставаться открытой гораздо дольше, чем 90 дней. + +`lifecycle/stale`: после 90 дней бездействия ишью автоматически помечается как устаревшая (stale). Такая заявка будет автоматически закрыта, если эта метка не будет удалена с помощью команды `/remove-lifecycle stale`. + +`lifecycle/frozen`: заявка с данной меткой не будет считаться устаревшей после 90 дней отсутствия активности. Пользователь вручную добавляет эту метку к заявкам, которые должны оставаться открытыми значительно дольше 90 дней, например, у ишью с меткой `priority/important-longterm`. + +### Обработка специальных типов ишью + +Мы встречаем перечисленные ниже типы заявкой достаточно часто, поэтому расписали, как их обрабатывать. + +#### Дублирование заявок + +Если для какой-нибудь проблемы есть одна или несколько открытых заявок, решение этой проблемы должно быть вынесено в одну заявку. Вам нужно решить, какую заявку оставить открытой (либо вовсе открыть новую ишью), перенести всю соответствующую информацию и указать связанные заявки. Затем для всех остальных похожих заявок добавьте метку с `triage/duplicate` и закройте их. Наличие только одной-единственной заявки поможет уменьшить путаницу и избежать дублирования работы над одной и той же проблемой. + +#### Заявки про неработающие ссылки + +В зависимости от того, где сообщается о неработающей ссылке, для решения этой проблемы требуются различные действия. Неработающие ссылки в API и документации Kubectl — это заявки, связанные с автоматизацией и поэтому их нужно отмечать меткой `/priority critical-urgent`, пока проблема не будет полностью проанализирована. Все остальные неработающие ссылки — это ишью, которым нужно заниматься вручную, поэтому им нужно добавить метку `/priority important-longterm`. + +#### Заявки, связанные с блогом + +Записи в [блоге Kubernetes](https://kubernetes.io/blog/) будут терять актуальность со временем, поэтому мы поддерживаем записи, опубликованные в течение года. Если заявка сообщает о проблеме в записи блога, которой более одного года, ее следует закрыть без какого-либо исправления. + +#### Заявки с помощью или отчёты об ошибке в коде + +Некоторые открытые заявки — это проблемы с основным кодом или просьбы с помощью, когда что-то (например, учебное руководство) не работает. Для заявок, не имеющих отношение к документации, закройте её, проставив метку `triage/support` и добавив комментарий с ресурсами, где можно найти помощь (Slack, Stack Overflow) и при необходимости укажите, где нужно открыть заявку, чтобы сообщить об ошибке в функциональности (вероятно, репозиторий kubernetes/kubernetes отлично подойдет для этого). + +Пример ответа на запрос о помощи: + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](http://slack.k8s.io/). You can also search +resources like +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in + https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + +Пример ответа на сообщение об ошибке в коде: + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + +## Добавление документации для новой функциональности + +Каждый мажорный выпуск Kubernetes несет в себе новую функциональность, для большей части из которой нужно написать хоть краткую документацию, чтобы показать людям, как её использовать. + +Зачастую SIG-группа, ответственная за новую функциональность, представляют черновик документацию в виде пулреквеста в соответствующую ветку выпуска в репозитории `kubernetes/website`, а кто-то из команды SIG Docs могут сделать вычитку или отредактировать черновик напрямую. + +### Поиск информации о новой функциональности + +Чтобы узнать о будущей функциональности, посетите еженедельную встречу sig-release (см. страницу [Сообщество](https://kubernetes.io/community/), чтобы быть в курсе предстоящих собраний) и отслеживайте документацию к новому релизу в репозитории [kubernetes/sig-release](https://github.com/kubernetes/sig-release/). Каждый выпуск имеет поддиректорию в директории [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases). Каждая директорию содержит график выхода новой версии, черновик с примечаниями к выпуску, а также документ, в котором перечислена команда, занимающаяся новым выпуском. + +- График выпуска содержит ссылки на все другие документы, встречи, протоколы собраний и этапы, связанные с выпуском. Он также содержит информацию о целях и сроках выпуска, а также о любых специальных процессах, используемых этом выпуске. В нижней части документа определены несколько терминов, связанных с выпуском. + + Этот документ также содержит ссылку на **лист отслеживания функциональности** — это "официальный" способ узнать про новую функциональность, запланированной в выпуске. + +- В документе команды выпуска указано, кто какую роль занимает. Если непонятно, с кем можно поговорить об определенной функциональности или вы хотите что-то спросить, то либо посетите встречу по этому выпуску, чтобы задать свой вопрос, либо обратитесь к руководителю. + +- Черновик примечаний к выпуску — хорошая отправная точка, где можно узнать чуть больше о конкретной функциональности, изменениях, устаревших возможностях и в целом что-то ещё о выпуске. Содержимое может обновляться до конца цикла выпуска, поэтому будьте начеку. + +#### Лист отслеживания функциональности + +В списке отслеживания функциональности [для данного выпуска Kubernetes](https://github.com/kubernetes/sig-release/tree/master/releases) перечислена вся функциональность, запланированная для выпуска. Каждая строка содержит название возможности, ссылку на основную заявку GitHub, уровень стабильности (Alpha, Beta или Stable), группу SIG и ответственного лица за её реализацию, информацию про документацию, черновик примечания для выпуска, а также указание, была ли функциональность уже принята. Имейте в виду следующее: + +- Функциональность в состоянии Beta и Stable обычно имеет более высокий приоритет по сравнению с версией Alpha. +- Трудно протестировать (и, следовательно, написать документацию) функциональности, которая не ещё принята или,по крайней мере, считается полнофункциональной в своем PR. +- Определение, нужна ли документировать функциональности, производится вручную, и даже если у функциональности нет метки, что ей нужна документация, это не означает, это действительно так. + +### Документирование функциональности + +Как отмечалось выше, черновик документации для новой функциональности обычно предлагается SIG-группой, ответственной за реализацию новой функциональности. Это означает, вы в данном случае будете больше наблюдающим (куратором) в данной функциональности, нежели чем полноценным автором документации для неё. + +После того, как вы выбрали функциональность для документирования/наблюдения, заявите об этом в Slack-канале `#sig-docs`, на еженедельной встрече sig-docs или напрямую в PR, отправленном SIG. Если вам дали добро, вы можете редактировать PR, используя один из способов, указанных в разделе [Редактирование PR другого человека](#редактирование-PR-другого-человека). + +Если вам нужно написать новую тему, полезны следующие ссылки: + +- [Написание новых тем](/docs/contribute/style/write-new-topic/) +- [Использование шаблонов страниц](/docs/contribute/style/page-templates/) +- [Руководство по оформлению документации](/docs/contribute/style/style-guide/) +- [Руководство по содержанию документации](/docs/contribute/style/content-guide/) + +### Члены SIG, участвующие в документировании новой функциональности + +Если вы участник SIG-группы, кто разрабатывает новую функциональность для Kubernetes, вам нужно работать с документацией SIG, чтобы убедиться, что на момент новой версии написана документация для этой функциональности. Проверьте [электронную таблицу с отслеживанием функциональности](https://github.com/kubernetes/sig-release/tree/master/releases) или присоединитесь в Slack-канал #sig-release, чтобы узнать информацию о сроках выхода. Некоторые крайние сроки касательно документации: + +- **Docs deadline - Open placeholder PRs**: откройте пулреквест в ветку `release-X.Y` в репозитории `kubernetes/website` с небольшим коммитом, который вы позже измените. Используйте команду Prow `/milestone X.Y`, чтобы назначить PR соответствующему этапу. Это уведомляет человека, который занимается документацией и ответственный за этот выпуск, что выходит документация для новой функциональности. Если функциональность не нуждается в каких-либо изменениях документации, убедитесь, что команда sig-release знает об этом, написав им сообщение в Slack-канале #sig-release. Если для функциональности нужна документация, но PR для этого ещё не создан, функциональность может быть удалена из этапа. +- **Docs deadline - PRs ready for review**: теперь ваш PR должен содержать первый черновик документации для вашей функциональности. Не беспокойтесь о форматировании или всяких улучшениях. Просто опишите, что делает эта функциональность и как ее использовать. Участник из группы документации, управляющий выпуском новой версии, будет работать вместе с вами, чтобы подготовить контент для публикации. Если вашей функциональности нужна документация и первого черновика с документацией до сих пор нет, эта функциональность может быть удалена из этапа. +- **Docs complete - All PRs reviewed and ready to merge**: если ваш PR еще не был объединен в ветку `release-X.Y` к заданному крайнему сроку, обратитесь за помощью к человеку, ответственному за выпуск новой версии. Если вашей функциональности требуется документация, но она ещё не сделана, функциональность может быть удалена из этапа. + +Если ваша функциональность находится в альфа-версии и ее не нельзя отключить, убедитесь, что вы добавили ее к [переключателем возможностей](/docs/reference/command-line-tools-reference/feature-gates/) в вашем пулреквесте. Если ваша функциональность переходит из альфа-версии, обязательно удалите ее из этого файла. + +## Участие к других репозиториях + +В [проекте Kubernetes](https://github.com/kubernetes) более 50 самостоятельных репозиториев. Многие из этих репозиториев хранят код или контент, который можно рассматривать как документацию, например, справочный текст для пользователях, сообщения об ошибках, пользовательский текст в справочниках API или даже комментарии кода. + +Если вы видите текст и не знаете, откуда он берётся, вы можете использовать поиск GitHub по репозиториям организации Kubernetes, чтобы выяснить, где встречается этот текст. Это поможет вам определиться с тем, куда создать заявку или PR. + +У каждого репозитория могут быть определены собственные процессы и правила. До того как открыть проблему или отправить PR, изучите файлы `README.md`, `CONTRIBUTING.md` и `code-of-conduct.md` в репозитории, если они есть. + +Большинство репозиториев используют шаблоны для заявок и PR. Просмотрите некоторые открытые заявки и PR, чтобы понять, как устроена работа. Обязательно как можно более подробно заполните шаблоны при открытии заявок или PR. + +## Локализация контента + +Английский является основным языком документации Kubernetes, однако мы хотим, чтобы у людей была возможность читать документацию на своём родном языке. Если вам комфортно писать на другом языке, особенно в теме программного обеспечения, вы можете помочь перевести документацию Kubernetes или помочь с существующим переводом. Посмотрите страницу [Локализация](/ru/docs/contribute/localization/) и задайте вопрос в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) или в канале `#sig-docs` на Slack, если вы хотите помочь. + +### Работа с локализованным контентом + +Старайтесь соблюдать эти рекомендации по работе с переведенным контентом: + +- В PR должны быть изменения касающиеся только одного языка. + + В каждом языке есть собственные рецензенты и утверждающие. + +- Рецензентам: убедитесь, что PR содержат изменения только на одном языке. + + Если PR изменяет файлы на нескольких языках, попросите автора открыть отдельные PR для каждого языка. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Если вы хорошо осознали все задачи, затронутые в этом разделе, и хотите более тесно работать с командой документации Kubernetes, переходите к изучению [продвинутого руководства участника](/ru/docs/contribute/advanced/). + +{{% /capture %}} From 7786c86454f9d7db7c2d32d48bfa88fbda2ba9db Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Mon, 2 Mar 2020 08:08:42 +0300 Subject: [PATCH 25/32] Translate Advanced contributing page into Russian (#19230) --- content/ru/docs/contribute/advanced.md | 196 +++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 content/ru/docs/contribute/advanced.md diff --git a/content/ru/docs/contribute/advanced.md b/content/ru/docs/contribute/advanced.md new file mode 100644 index 0000000000..b450c088b5 --- /dev/null +++ b/content/ru/docs/contribute/advanced.md @@ -0,0 +1,196 @@ +--- +title: Участие для опытных +slug: advanced +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +На этой странице предполагается, что вы изучили темы [Участие для начинающих](/ru/docs/contribute/start/) и [Участие для опытных](/ru/docs/contribute/intermediate/) и теперь хотите узнать ещё больше про то, как можно помочь проекту. Для решения некоторых задач вам потребуется использовать Git из командной строки и прочие другие инструменты. + +{{% /capture %}} + +{{% capture body %}} + +## Дежурный по PR на неделю + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) группы SIG Docs регулярно по очереди становятся дежурными по PR в репозитории и поэтому участвуют в [графике ротации PR-дежурного](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) на неделю. + +В обязанности дежурного по PR входят: + +- Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/). + - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`). + - Проверяйте столько пулреквестов, сколько сможете. +- Проследить, что CLA подписан каждым участником. + - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA. +- Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп. + - Предложить исправления для измененного контента в PR. + - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы. + - Добавьте нужны метки с `sig/`. + - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла. + - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR. + - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены. + - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием. + - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты. +- Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты. +- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs. + +### Полезные ссылки на GitHub для дежурных + +Следующие ссылки помогут при дежурстве. После обработки заявок по трём первым ссылкам, как правило, список пулреквестов для проверки сократится. По указанным ссылкам вы найдете PR только в английскую версию, предназначенные для слияния в ветку `master` (кроме последней ссылки). + +- [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA. +**Не проверяйте PR, если их авторы не подписали CLA!** +- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста. +- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`. +- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]). +- [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку. + +### Когда закрывать пулреквесты + +Обзоры и одобрения — это только один из способов, позволяющих держать список PR коротким и актуальным. Закрытие пулреквестов — альтернативный метод для этого. + +- Можете закрыть любой PR, если CLA-соглашение не было подписано в течение двух недель. +Авторы PR могут повторно открыть PR после подписания CLA, так что это безопасный способ убедиться, что ничто не будет объединено без подписанного CLA. + +- Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель. + +Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад. + +Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR. + +{{< note >}} + +Бот [`fejta-bot`](https://github.com/fejta-bot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия. + +{{< /note >}} + +## Внесение улучшений + +[Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения. + +После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com). + +Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing. + +## Координация документации по выпуску Kubernetes + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут координировать документацию для выпуска Kubernetes. + +Каждый выпуск Kubernetes координируется командой людей, участвующих в специальной группе (Special Interest Group, SIG) sig-release. Другие члены команды в данном выпуске включают в себя общего руководителя выпуском, а также представителей sig-pm, sig-testing и др. Чтобы узнать больше о процессах выпуска версий Kubernetes, обратитесь к [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). + +Представитель SIG Docs для данного выпуска координирует следующие задачи: + +- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск. +- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске. +- Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности. +- Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска. +- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing). +- Публикация изменений в документации, связанные с выпуском при размещении артефактов. + +Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs. + +## Амбассадор нового участника + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут выступать в качестве амбассадоров новых участников. + +Амбассадоры новых участников работают бок о бок, чтобы поприветствовать новых участников SIG Docs, предлагать PR новым участникам и консультировать новых участников в их собственных PR. + +Обязанности амбассадоров новых участников включают в себя: + +- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com). +- Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками. +- Консультировать новых участников в их PR. +- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes. +- [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes. + +Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com). + +## Поддержка нового участника + +[Рецензенты](/ru/docs/contribute/participating/#рецензенты) SIG Docs могут содействовать новым участникам в членстве организации. + +Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами. + +Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes. + +## Сопредседатель SIG + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут быть сопредседателями SIG Docs. + +### Требования + +Сопредседатели должны соответствовать следующим требованиям: + +- Быть утверждающим SIG Docs не меньше 6 месяцев +- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска +- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог +- Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). +- Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей. + +### Обязанности + +Роль сопредседателя посвящена в основном одной из задач: сопредседатели управляют процессом и политикой, планируют и проводят собрания, назначают дежурных по PR и, как правило, делают то, что никто больше не хочет делать, для увеличения количества участников. + +Обязанности включают в себя: + +- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию +- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG +- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию +- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое +- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях +- Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei. +- Поддерживать нормальную работу SIG + +### Проведение продуктивных встреч + +Для планирования и проведения результативных встреч мы составили рекомендации, которые показывают и объясняют, как лучше всего их подготовить. + +**Соблюдайте [нормы поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**: + +- Привлекайте самый широкий круг участников к дискуссии и уважительно общайтесь между собой, стараясь никого не обидеть. + +**Сформулируйте четкую повестку дня**: + +- Определите конкретную цель встречи +- Опубликуйте программу дня заранее + +Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings". + +**Работайте вместе для создания точных примечания**: + +- Запишите обсуждение встречи +- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому + +**Определяйте решения по пунктам повестки четко и точно**: + +- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения + +**Руководите обсуждением, когда это необходимо**: + +- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему +- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей + +**Уважайте время людей**: + +- Начинайте и заканчивайте встречи своевременно + +**Используйте Zoom эффективно**: + +- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md) +- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего + +Исполнение роли ведущего в Zoom + +### Запись встреч на Zoom + +Когда вам потребуется начать запись, нажмите пункт с надписью Record to Cloud. + +Если нужно остановить запись, нажмите на кнопку Stop. + +Запись автоматически загрузится на YouTube. + +{{% /capture %}} From 653fd205f763cba93bddd9f6210c3569bc981ac7 Mon Sep 17 00:00:00 2001 From: Merlin Dienst Date: Mon, 2 Mar 2020 12:10:42 +0100 Subject: [PATCH 26/32] Fixed typo in German kubernetes concepts (#19432) Kommanduzeilen -> Kommandozeilen --- content/de/docs/concepts/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/concepts/_index.md b/content/de/docs/concepts/_index.md index b8fc0272db..82b5b0e5b0 100644 --- a/content/de/docs/concepts/_index.md +++ b/content/de/docs/concepts/_index.md @@ -52,7 +52,7 @@ Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, ### Kubernetes Master -Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. +Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. > Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen. From 007080e2d212d0713cd425e4eed6b004fb8b9f9e Mon Sep 17 00:00:00 2001 From: Merlin Dienst Date: Mon, 2 Mar 2020 12:44:42 +0100 Subject: [PATCH 27/32] Fixed typo in line 208 (#19326) importORtieren -> importieren --- content/de/docs/setup/minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index f4d19ea80c..06734bd28f 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen -Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. +Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell: From 9865699335611228894bebe1140c8aad8cb23ac1 Mon Sep 17 00:00:00 2001 From: Ihor Sychevskyi <26163841+Arhell@users.noreply.github.com> Date: Tue, 3 Mar 2020 00:27:38 +0200 Subject: [PATCH 28/32] fix image display in firefox browser (#19421) --- assets/sass/_tablet.sass | 3 +++ 1 file changed, 3 insertions(+) diff --git a/assets/sass/_tablet.sass b/assets/sass/_tablet.sass index 96b24322a2..90215de1af 100644 --- a/assets/sass/_tablet.sass +++ b/assets/sass/_tablet.sass @@ -133,18 +133,21 @@ $feature-box-div-width: 45% max-width: 25% max-height: 100% transform: translateY(-50%) + width: 100% &:nth-child(odd) padding-right: 210px .image-wrapper right: 0 + text-align: right &:nth-child(even) padding-left: 210px .image-wrapper left: 0 + text-align: left &:nth-child(1) padding-right: 0 From 06409da263b209483ccd9528b27a186cb80c6c38 Mon Sep 17 00:00:00 2001 From: Cria Hu Date: Tue, 3 Mar 2020 15:07:37 +0800 Subject: [PATCH 29/32] Modify sentences with poor translation (#19330) * Modify sentences with poor translation * Modify sentences with poor translation --- content/zh/docs/concepts/architecture/cloud-controller.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index f3bdc03e1f..f313808371 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -235,19 +235,19 @@ The Service controller is responsible for listening to service create, update, a The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM. --> -节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 +节点控制器包含 kubelet 中云依赖的功能，在引入 CCM 之前，kubelet 负责使用特定于云平台的功能特性（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。