From b05129acc31a69c5584ef1458ace701fa99957ff Mon Sep 17 00:00:00 2001 From: Yushiro FURUKAWA Date: Tue, 15 Oct 2019 18:23:51 +0900 Subject: [PATCH] Remove trailing spaces from zh documents(#16742) (#16794) --- content/zh/OWNERS | 2 +- content/zh/blog/_index.md | 4 +- .../2018-06-28-Airflow-Kubernetes-Operator.md | 226 +++++++++--------- ...18-07-09-IPVS-In-Cluster-Load-Balancing.md | 48 ++-- .../2018-12-05-new-contributor-shanghai.md | 36 +-- content/zh/docs/concepts/_index.md | 30 +-- .../concepts/architecture/cloud-controller.md | 2 +- .../architecture/master-node-communication.md | 2 +- .../cluster-administration/certificates.md | 14 +- .../cluster-administration/cloud-providers.md | 10 +- .../cluster-administration/logging.md | 2 +- .../cluster-administration/proxies.md | 2 +- .../manage-compute-resources-container.md | 28 +-- .../organize-cluster-access-kubeconfig.md | 4 +- .../docs/concepts/configuration/overview.md | 6 +- .../zh/docs/concepts/configuration/secret.md | 16 +- .../configuration/taint-and-toleration.md | 2 +- .../container-environment-variables.md | 2 +- content/zh/docs/concepts/containers/images.md | 2 +- .../docs/concepts/containers/runtime-class.md | 26 +- .../api-extension/apiserver-aggregation.md | 4 +- .../docs/concepts/overview/kubernetes-api.md | 12 +- .../working-with-objects/annotations.md | 2 +- .../kubernetes-objects.md | 2 +- .../working-with-objects/namespaces.md | 6 +- .../docs/concepts/policy/resource-quotas.md | 6 +- ...ries-to-pod-etc-hosts-with-host-aliases.md | 2 +- .../connect-applications-service.md | 8 +- .../services-networking/dns-pod-service.md | 10 +- .../ingress-controllers.md | 28 +-- .../concepts/services-networking/ingress.md | 14 +- .../services-networking/network-policies.md | 6 +- .../concepts/services-networking/service.md | 32 +-- .../docs/concepts/storage/storage-classes.md | 22 +- .../docs/concepts/storage/storage-limits.md | 20 +- .../storage/volume-snapshot-classes.md | 12 +- content/zh/docs/concepts/storage/volumes.md | 20 +- .../workloads/controllers/cron-jobs.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/pods/init-containers.md | 4 +- .../docs/concepts/workloads/pods/podpreset.md | 6 +- .../admission-controllers.md | 14 +- .../access-authn-authz/authorization.md | 6 +- .../access-authn-authz/controlling-access.md | 4 +- .../service-accounts-admin.md | 2 +- .../kube-apiserver.md | 78 +++--- .../kubelet-tls-bootstrapping.md | 2 +- content/zh/docs/reference/glossary/ingress.md | 4 +- .../kubectl/docker-cli-to-kubectl.md | 4 +- content/zh/docs/reference/kubectl/kubectl.md | 2 +- .../docs/reference/kubernetes-api/_index.md | 2 +- .../labels-annotations-taints.md | 12 +- .../setup-tools/kubeadm/kubeadm-init.md | 2 +- content/zh/docs/reference/tools.md | 8 +- .../independent/create-cluster-kubeadm.md | 54 ++--- .../docs/setup/independent/install-kubeadm.md | 92 +++---- .../access-cluster.md | 28 +-- .../configure-cloud-provider-firewall.md | 8 +- .../configure-dns-cluster.md | 2 +- ...load-balance-access-application-cluster.md | 4 +- ...port-forward-access-application-cluster.md | 20 +- .../service-access-application-cluster.md | 2 +- .../setup-extension-api-server.md | 2 +- .../apply-resource-quota-limit.md | 4 +- .../change-default-storage-class.md | 2 +- .../change-pv-reclaim-policy.md | 4 +- .../administer-cluster/cluster-management.md | 2 +- .../declare-network-policy.md | 4 +- .../dns-custom-nameservers.md | 2 +- .../kubeadm/kubeadm-upgrade-1-9.md | 20 +- .../memory-default-namespace.md | 2 +- .../calico-network-policy.md | 6 +- .../cilium-network-policy.md | 12 +- .../romana-network-policy.md | 4 +- .../weave-network-policy.md | 8 +- .../quota-mem-cpu-pod-2.yaml | 4 +- .../administer-cluster/quota-mem-cpu-pod.yaml | 4 +- .../attach-handler-lifecycle-event.md | 4 +- .../rq-compute-resources.yaml | 2 +- .../security-context-2.yaml | 2 +- .../security-context.yaml | 2 +- .../tasks/debug-application-cluster/audit.md | 4 +- .../debug-application.md | 46 ++-- .../debug-cluster.md | 6 +- .../define-command-argument-container.md | 4 +- .../distribute-credentials-secure.md | 14 +- ...nward-api-volume-expose-pod-information.md | 2 +- .../inject-data-application/podpreset.md | 2 +- .../job/automated-tasks-with-cron-jobs.md | 6 +- .../fine-parallel-processing-work-queue.md | 2 +- .../manage-daemon/rollback-daemon-set.md | 6 +- .../docs/tasks/manage-gpus/scheduling-gpus.md | 16 +- .../run-application/delete-stateful-set.md | 2 +- .../rolling-update-replication-controller.md | 2 +- .../zh/docs/tasks/tls/certificate-rotation.md | 6 +- .../kubernetes-basics/scale/scale-intro.html | 4 +- .../imperative-object-management-command.md | 2 +- .../object-management.md | 2 +- .../zh/docs/tutorials/services/source-ip.md | 2 +- .../basic-stateful-set.md | 18 +- .../stateful-application/zookeeper.md | 10 +- .../stateful-application/zookeeper.yaml | 4 +- .../admin/resource/quota-mem-cpu-pod-2.yaml | 4 +- .../admin/resource/quota-mem-cpu-pod.yaml | 4 +- .../examples/application/job/redis/worker.py | 2 +- .../zh/includes/federation-content-moved.md | 2 +- 106 files changed, 648 insertions(+), 648 deletions(-) diff --git a/content/zh/OWNERS b/content/zh/OWNERS index 8040070fdb..6e147c98ad 100644 --- a/content/zh/OWNERS +++ b/content/zh/OWNERS @@ -1,7 +1,7 @@ # See the OWNERS docs at https://go.k8s.io/owners # This is the localization project for Chinese. -# Teams and members are visible at https://github.com/orgs/kubernetes/teams. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. reviewers: - sig-docs-zh-reviews diff --git a/content/zh/blog/_index.md b/content/zh/blog/_index.md index 692088e653..511fedd1b3 100644 --- a/content/zh/blog/_index.md +++ b/content/zh/blog/_index.md @@ -9,7 +9,7 @@ menu:

阅读关于 kubernetes 和容器规范的最新信息,以及获取最新的技术。

--- - diff --git a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md index 6ff8dc79c8..f0718cac7e 100644 --- a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md +++ b/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md @@ -21,41 +21,41 @@ Author: Daniel Imberman (Bloomberg LP) --> - + 作者: Daniel Imberman (Bloomberg LP) - + - + ## 介绍 - + 作为Bloomberg [继续致力于开发Kubernetes生态系统]的一部分（https://www.techatbloomberg.com/blog/bloomberg-awarded-first-cncf-end-user-award-contributions-kubernetes/），我们很高兴能够宣布Kubernetes Airflow Operator的发布; [Apache Airflow]（https://airflow.apache.org/）的机制，一种流行的工作流程编排框架，使用Kubernetes API可以在本机启动任意的Kubernetes Pod。 - + - + ## 什么是Airflow? - + Apache Airflow是DevOps“Configuration As Code”理念的一种实现。 Airflow允许用户使用简单的Python对象DAG（有向无环图）启动多步骤流水线。 您可以在易于阅读的UI中定义依赖关系，以编程方式构建复杂的工作流，并监视调度的作业。 - + - + - + ## 为什么在Kubernetes上使用Airflow? - + 自成立以来，Airflow的最大优势在于其灵活性。 Airflow提供广泛的服务集成，包括Spark和HBase，以及各种云提供商的服务。 Airflow还通过其插件框架提供轻松的可扩展性。但是，该项目的一个限制是Airflow用户仅限于执行时Airflow站点上存在的框架和客户端。单个组织可以拥有各种Airflow工作流程，范围从数据科学流到应用程序部署。用例中的这种差异会在依赖关系管理中产生问题，因为两个团队可能会在其工作流程使用截然不同的库。 - + 为了解决这个问题，我们使Kubernetes允许用户启动任意Kubernetes pod和配置。 Airflow用户现在可以在其运行时环境，资源和机密上拥有全部权限，基本上将Airflow转变为“您想要的任何工作”工作流程协调器。 - + - + ## Kubernetes运营商 - + 在进一步讨论之前，我们应该澄清Airflow中的[Operator]（https://airflow.apache.org/concepts.html#operators）是一个任务定义。 当用户创建DAG时，他们将使用像“SparkSubmitOperator”或“PythonOperator”这样的operator分别提交/监视Spark作业或Python函数。 Airflow附带了Apache Spark，BigQuery，Hive和EMR等框架的内置运算符。 它还提供了一个插件入口点，允许DevOps工程师开发自己的连接器。 - + Airflow用户一直在寻找更易于管理部署和ETL流的方法。 在增加监控的同时，任何解耦流程的机会都可以减少未来的停机等问题。 以下是Airflow Kubernetes Operator提供的好处： - + - + * 提高部署灵活性： Airflow的插件API一直为希望在其DAG中测试新功能的工程师提供了重要的福利。 不利的一面是，每当开发人员想要创建一个新的operator时，他们就必须开发一个全新的插件。 现在，任何可以在Docker容器中运行的任务都可以通过完全相同的运算符访问，而无需维护额外的Airflow代码。 - + - + * 配置和依赖的灵活性： 对于在静态Airflow工作程序中运行的operator，依赖关系管理可能变得非常困难。 如果开发人员想要运行一个需要[SciPy]（https://www.scipy.org） 的任务和另一个需要[NumPy]（http://www.numpy.org） 的任务，开发人员必须维护所有Airflow节点中的依赖关系或将任务卸载到其他计算机（如果外部计算机以未跟踪的方式更改，则可能导致错误）。 自定义Docker镜像允许用户确保任务环境，配置和依赖关系完全是幂等的。 - + - + * 使用kubernetes Secret以增加安全性： 处理敏感数据是任何开发工程师的核心职责。 Airflow用户总有机会在严格条款的基础上隔离任何API密钥，数据库密码和登录凭据。 使用Kubernetes运算符，用户可以利用Kubernetes Vault技术存储所有敏感数据。 这意味着Airflow工作人员将永远无法访问此信息，并且可以容易地请求仅使用他们需要的密码信息构建pod。 - + - + ＃架构 - + - + Kubernetes Operator使用[Kubernetes Python客户端]（https://github.com/kubernetes-client/Python)生成由APIServer处理的请求（1）。 然后，Kubernetes将使用您定义的需求启动您的pod（2）。映像文件中将加载环境变量，Secret和依赖项，执行单个命令。 一旦启动作业，operator只需要监视跟踪日志的状况（3）。 用户可以选择将日志本地收集到调度程序或当前位于其Kubernetes集群中的任何分布式日志记录服务。 - + - + ＃使用Kubernetes Operator - + ##一个基本的例子 - + 以下DAG可能是我们可以编写的最简单的示例，以显示Kubernetes Operator的工作原理。 这个DAG在Kubernetes上创建了两个pod：一个带有Python的Linux发行版和一个没有它的基本Ubuntu发行版。 Python pod将正确运行Python请求，而没有Python的那个将向用户报告失败。 如果Operator正常工作，则应该完成“passing-task”pod，而“falling-task”pod则向Airflow网络服务器返回失败。 - - + + ```Python @@ -272,7 +272,7 @@ default_args = { } - + dag = DAG( @@ -329,29 +329,29 @@ failing.set_upstream(start) ## But how does this relate to my workflow? - + While this example only uses basic images, the magic of Docker is that this same DAG will work for any image/command pairing you want. The following is a recommended CI/CD pipeline to run production-ready code on an Airflow DAG. - + ### 1: PR in github Use Travis or Jenkins to run unit and integration tests, bribe your favorite team-mate into PR'ing your code, and merge to the master branch to trigger an automated CI build. - + ### 2: CI/CD via Jenkins -> Docker Image - + Generate your Docker images and bump release version within your Jenkins build. - + ### 3: Airflow launches task - + Finally, update your DAGs to reflect the new release version and you should be ready to go! @@ -359,33 +359,33 @@ Finally, update your DAGs to reflect the new release version and you should be r ##但这与我的工作流程有什么关系？ - + 虽然这个例子只使用基本映像，但Docker的神奇之处在于，这个相同的DAG可以用于您想要的任何图像/命令配对。 以下是推荐的CI / CD管道，用于在Airflow DAG上运行生产就绪代码。 - + ### 1：github中的PR 使用Travis或Jenkins运行单元和集成测试，请您的朋友PR您的代码，并合并到主分支以触发自动CI构建。 - + ### 2：CI / CD构建Jenkins - > Docker Image - + [在Jenkins构建中生成Docker镜像和缓冲版本]（https://getintodevops.com/blog/building-your-first-Docker-image-with-jenkins-2-guide-for-developers）。 - + ### 3：Airflow启动任务 - + 最后，更新您的DAG以反映新版本，您应该准备好了！ - + ```Python @@ -415,61 +415,61 @@ production_task = KubernetesPodOperator(namespace='default', # Launching a test deployment - + Since the Kubernetes Operator is not yet released, we haven't released an official helm chart or operator (however both are currently in progress). However, we are including instructions for a basic deployment below and are actively looking for foolhardy beta testers to try this new feature. To try this system out please follow these steps: - + ## Step 1: Set your kubeconfig to point to a kubernetes cluster - + ## Step 2: Clone the Airflow Repo: - + Run git clone https://github.com/apache/incubator-airflow.git to clone the official Airflow repo. - + ## Step 3: Run - + To run this basic deployment, we are co-opting the integration testing script that we currently use for the Kubernetes Executor (which will be explained in the next article of this series). To launch this deployment, run these three commands: --> - + ＃启动测试部署 - + 由于Kubernetes运营商尚未发布，我们尚未发布官方[helm](https://helm.sh/) 图表或operator（但两者目前都在进行中）。 但是，我们在下面列出了基本部署的说明，并且正在积极寻找测试人员来尝试这一新功能。 要试用此系统，请按以下步骤操作： - + ##步骤1：将kubeconfig设置为指向kubernetes集群 - + ##步骤2：clone Airflow 仓库： - + 运行git clone https：// github.com / apache / incubator-airflow.git来clone官方Airflow仓库。 - + ##步骤3：运行 - + 为了运行这个基本Deployment，我们正在选择我们目前用于Kubernetes Executor的集成测试脚本（将在本系列的下一篇文章中对此进行解释）。 要启动此部署，请运行以下三个命令： - + ``` @@ -485,77 +485,77 @@ sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/config Before we move on, let's discuss what these commands are doing: - + ### sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml - + The Kubernetes Executor is another Airflow feature that allows for dynamic allocation of tasks as idempotent pods. The reason we are switching this to the LocalExecutor is simply to introduce one feature at a time. You are more then welcome to skip this step if you would like to try the Kubernetes Executor, however we will go into more detail in a future article. - + ### ./scripts/ci/kubernetes/Docker/build.sh - + This script will tar the Airflow master source code build a Docker container based on the Airflow distribution - + ### ./scripts/ci/kubernetes/kube/deploy.sh - + Finally, we create a full Airflow deployment on your cluster. This includes Airflow configs, a postgres backend, the webserver + scheduler, and all necessary services between. One thing to note is that the role binding supplied is a cluster-admin, so if you do not have that level of permission on the cluster, you can modify this at scripts/ci/kubernetes/kube/airflow.yaml - + ## Step 4: Log into your webserver - + Now that your Airflow instance is running let's take a look at the UI! The UI lives in port 8080 of the Airflow pod, so simply run --> - + 在我们继续之前，让我们讨论这些命令正在做什么： - + ### sed -ie“s / KubernetesExecutor / LocalExecutor / g”scripts / ci / kubernetes / kube / configmaps.yaml - + Kubernetes Executor是另一种Airflow功能，允许动态分配任务已解决幂等pod的问题。我们将其切换到LocalExecutor的原因只是一次引入一个功能。如果您想尝试Kubernetes Executor，欢迎您跳过此步骤，但我们将在以后的文章中详细介绍。 - + ### ./scripts/ci/kubernetes/Docker/build.sh - + 此脚本将对Airflow主分支代码进行打包，以根据Airflow的发行文件构建Docker容器 - + ### ./scripts/ci/kubernetes/kube/deploy.sh - + 最后，我们在您的群集上创建完整的Airflow部署。这包括Airflow配置，postgres后端，webserver +调度程序以及之间的所有必要服务。需要注意的一点是，提供的角色绑定是集群管理员，因此如果您没有该集群的权限级别，可以在scripts / ci / kubernetes / kube / airflow.yaml中进行修改。 - + ##步骤4：登录您的网络服务器 - + 现在您的Airflow实例正在运行，让我们来看看UI！用户界面位于Airflow pod的8080端口，因此只需运行即可 - + ``` @@ -569,59 +569,59 @@ kubectl port-forward $WEB 8080:8080 Now the Airflow UI will exist on http://localhost:8080. To log in simply enter airflow/airflow and you should have full access to the Airflow web UI. - + ## Step 5: Upload a test document - + To modify/add your own DAGs, you can use kubectl cp to upload local files into the DAG folder of the Airflow scheduler. Airflow will then read the new DAG and automatically upload it to its system. The following command will upload any local file into the correct directory: --> - + 现在，Airflow UI将存在于http://localhost:8080上。 要登录，只需输入airflow /airflow，您就可以完全访问Airflow Web UI。 - + ##步骤5：上传测试文档 - + 要修改/添加自己的DAG，可以使用kubectl cp将本地文件上传到Airflow调度程序的DAG文件夹中。 然后，Airflow将读取新的DAG并自动将其上传到其系统。 以下命令将任何本地文件上载到正确的目录中： - + kubectl cp /:/root/airflow/dags -c scheduler - + - + ##步骤6：使用它！ - + #那么我什么时候可以使用它？ - + 虽然此功能仍处于早期阶段，但我们希望在未来几个月内发布该功能以进行广泛发布。 - + #参与其中 - + 此功能只是将Apache Airflow集成到Kubernetes中的多项主要工作的开始。 Kubernetes Operator已合并到[Airflow的1.10发布分支]（https://github.com/apache/incubator-airflow/tree/v1-10-test）（实验模式中的执行模块），以及完整的k8s本地调度程序称为Kubernetes Executor（即将发布文章）。这些功能仍处于早期采用者/贡献者可能对这些功能的未来产生巨大影响的阶段。 - + 对于有兴趣加入这些工作的人，我建议按照以下步骤： - + *加入airflow-dev邮件列表dev@airflow.apache.org。 @@ -671,6 +671,6 @@ Special thanks to the Apache Airflow and Kubernetes communities, particularly Gr *在kubernetes.slack.com上的＃sig-big-data找到我们。 - + 特别感谢Apache Airflow和Kubernetes社区，特别是Grant Nicholas，Ben Goldberg，Anirudh Ramanathan，Fokko Dreisprong和Bolke de Bruin，感谢您对这些功能的巨大帮助以及我们未来的努力。 diff --git a/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md b/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md index 560fe618bc..1d6ed8025e 100644 --- a/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md +++ b/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md @@ -176,21 +176,21 @@ Here comes an example: Port: http 3080/TCP Endpoints: 10.244.0.235:8080,10.244.1.237:8080 Session Affinity: None - + # ip addr ... 73: kube-ipvs0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff inet 10.102.128.4/32 scope global kube-ipvs0 valid_lft forever preferred_lft forever - + # ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags - -> RemoteAddress:Port Forward Weight ActiveConn InActConn + -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.102.128.4:3080 rr - -> 10.244.0.235:8080 Masq 1 0 0 - -> 10.244.1.237:8080 Masq 1 0 0 + -> 10.244.0.235:8080 Masq 1 0 0 + -> 10.244.1.237:8080 Masq 1 0 0 --> @@ -204,21 +204,21 @@ Here comes an example: Port: http 3080/TCP Endpoints: 10.244.0.235:8080,10.244.1.237:8080 Session Affinity: None - + # ip addr ... 73: kube-ipvs0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff inet 10.102.128.4/32 scope global kube-ipvs0 valid_lft forever preferred_lft forever - + # ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags - -> RemoteAddress:Port Forward Weight ActiveConn InActConn + -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.102.128.4:3080 rr - -> 10.244.0.235:8080 Masq 1 0 0 - -> 10.244.1.237:8080 Masq 1 0 0 + -> 10.244.0.235:8080 Masq 1 0 0 + -> 10.244.1.237:8080 Masq 1 0 0 - 设置名称 成员 用法 + 设置名称 成员 用法 KUBE-CLUSTER-IP 所有服务 IP + 端口 masquerade-all=true 或 clusterCIDR 指定的情况下进行伪装 - KUBE-LOOP-BACK 所有服务 IP +端口+ IP 解决数据包欺骗问题 - KUBE-EXTERNAL-IP 服务外部 IP +端口 将数据包伪装成外部 IP - KUBE-LOAD-BALANCER 负载均衡器入口 IP +端口 将数据包伪装成 Load Balancer 类型的服务 + KUBE-LOOP-BACK 所有服务 IP +端口+ IP 解决数据包欺骗问题 + KUBE-EXTERNAL-IP 服务外部 IP +端口 将数据包伪装成外部 IP + KUBE-LOAD-BALANCER 负载均衡器入口 IP +端口 将数据包伪装成 Load Balancer 类型的服务 KUBE-LOAD-BALANCER-LOCAL 负载均衡器入口 IP +端口 以及 externalTrafficPolicy=local 接受数据包到 Load Balancer externalTrafficPolicy=local KUBE-LOAD-BALANCER-FW 负载均衡器入口 IP +端口 以及 loadBalancerSourceRanges 使用指定的 loadBalancerSourceRanges 丢弃 Load Balancer类型Service的数据包 KUBE-LOAD-BALANCER-SOURCE-CIDR 负载均衡器入口 IP +端口 + 源 CIDR 接受 Load Balancer 类型 Service 的数据包，并指定loadBalancerSourceRanges - KUBE-NODE-PORT-TCP NodePort 类型服务 TCP 将数据包伪装成 NodePort（TCP） + KUBE-NODE-PORT-TCP NodePort 类型服务 TCP 将数据包伪装成 NodePort（TCP） KUBE-NODE-PORT-LOCAL-TCP NodePort 类型服务 TCP 端口，带有 externalTrafficPolicy=local 接受数据包到 NodePort 服务 使用 externalTrafficPolicy=local - KUBE-NODE-PORT-UDP NodePort 类型服务 UDP 端口 将数据包伪装成 NodePort(UDP) + KUBE-NODE-PORT-UDP NodePort 类型服务 UDP 端口 将数据包伪装成 NodePort(UDP) KUBE-NODE-PORT-LOCAL-UDP NodePort 类型服务 UDP 端口 使用 externalTrafficPolicy=local 接受数据包到NodePort服务 使用 externalTrafficPolicy=local - **作者**: Josh Berkus (红帽), Yang Li (The Plant), Puja Abbassi (Giant Swarm), XiangPeng Zhao (中兴通讯) - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/attendees.png" caption="KubeCon 上海站新贡献者峰会与会者，摄影：Jerry Zhang" >}} - 最近，在中国的首次 KubeCon 上，我们完成了在中国的首次新贡献者峰会。看到所有中国和亚洲的开发者（以及来自世界各地的一些人）有兴趣成为贡献者，这令人非常兴奋。在长达一天的课程中，他们了解了如何、为什么以及在何处为 Kubernetes 作出贡献，创建了 PR，参加了贡献者圆桌讨论，并签署了他们的 CLA。 - 这是我们的第二届新贡献者工作坊（NCW），它由前一次贡献者体验 SIG 成员创建和领导的哥本哈根研讨会延伸而来。根据受众情况，本次活动采用了中英文两种语言，充分利用了 CNCF 赞助的一流的同声传译服务。同样，NCW 团队由社区成员组成，既有说英语的，也有说汉语的：Yang Li、XiangPeng Zhao、Puja Abbassi、Noah Abrahams、Tim Pepper、Zach Corleissen、Sen Lu 和 Josh Berkus。除了演讲和帮助学员外，团队的双语成员还将所有幻灯片翻译成了中文。共有五十一名学员参加。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/noahabrahams.png" caption="Noah Abrahams 讲解 Kubernetes 沟通渠道。摄影：Jerry Zhang" >}} - NCW 让参与者完成了为 Kubernetes 作出贡献的各个阶段，从决定在哪里作出贡献开始，接着介绍了 SIG 系统和我们的代码仓库结构。我们还有来自文档和测试基础设施领域的「客座讲者」，他们负责讲解有关的贡献。最后，我们在创建 issue、提交并批准 PR 的实践练习后，结束了工作坊。 - 这些实践练习使用一个名为[贡献者游乐场](https://github.com/kubernetes-sigs/contributor-playground)的代码仓库，由贡献者体验 SIG 创建，让新贡献者尝试在一个 Kubernetes 仓库中执行各种操作。它修改了 Prow 和 Tide 自动化，使用与真实代码仓库类似的 Owners 文件。这可以让学员了解为我们的仓库做出贡献的有关机制，同时又不妨碍正常的开发流程。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/yangli.png" caption="Yang Li 讲到如何让你的 PR 通过评审。摄影：Josh Berkus" >}} - 「防火长城」和语言障碍都使得在中国为 Kubernetes 作出贡献变得困难。而且，中国的开源商业模式并不成熟，员工在开源项目上工作的时间有限。 - 中国工程师渴望参与 Kubernetes 的研发，但他们中的许多人不知道从何处开始，因为 Kubernetes 是一个如此庞大的项目。通过本次工作坊，我们希望帮助那些想要参与贡献的人，不论他们希望修复他们遇到的一些错误、改进或本地化文档，或者他们需要在工作中用到 Kubernetes。我们很高兴看到越来越多的中国贡献者在过去几年里加入社区，我们也希望将来可以看到更多。 - 「我已经参与了 Kubernetes 社区大约三年」，XiangPeng Zhao 说，「在社区，我注意到越来越多的中国开发者表现出对 Kubernetes 贡献的兴趣。但是，开始为这样一个项目做贡献并不容易。我尽力帮助那些我在社区遇到的人，但是，我认为可能仍有一些新的贡献者离开社区，因为他们在遇到麻烦时不知道从哪里获得帮助。幸运的是，社区在 KubeCon 哥本哈根站发起了 NCW，并在 KubeCon 上海站举办了第二届。我很高兴受到 Josh Berkus 的邀请，帮助组织这个工作坊。在工作坊期间，我当面见到了社区里的朋友，在练习中指导了与会者，等等。所有这些对我来说都是难忘的经历。作为有着多年贡献者经验的我，也学习到了很多。我希望几年前我开始为 Kubernetes 做贡献时参加过这样的工作坊」。 - {{< figure src="/images/blog/2018-12-05-new-contributor-shanghai/panel.png" caption="贡献者圆桌讨论。摄影：Jerry Zhang" >}} - 工作坊以现有贡献者圆桌讨论结束，嘉宾包括 Lucas Käldström、Janet Kuo、Da Ma、Pengfei Ni、Zefeng Wang 和 Chao Xu。这场圆桌讨论旨在让新的和现有的贡献者了解一些最活跃的贡献者和维护者的幕后日常工作，不论他们来自中国还是世界各地。嘉宾们讨论了从哪里开始贡献者的旅程，以及如何与评审者和维护者进行互动。他们进一步探讨了在中国参与贡献的主要问题，并向与会者预告了在 Kubernetes 的未来版本中可以期待的令人兴奋的功能。 - 工作坊结束后，XiangPeng Zhao 和一些与会者就他们的经历在微信和 Twitter 上进行了交谈。他们很高兴参加了 NCW，并就改进工作坊提出了一些建议。一位名叫 Mohammad 的与会者说：「我在工作坊上玩得很开心，学习了参与 k8s 贡献的整个过程。」另一位与会者 Jie Jia 说：「工作坊非常精彩。它系统地解释了如何为 Kubernetes 做出贡献。即使参与者之前对此一无所知，他（她）也可以理解这个过程。对于那些已经是贡献者的人，他们也可以学习到新东西。此外，我还可以在工作坊上结识来自国内外的新朋友。真是棒极了！」 - 贡献者体验 SIG 将继续在未来的 KubeCon 上举办新贡献者工作坊，包括西雅图站、巴塞罗那站，然后在 2019 年六月回到上海。如果你今年未能参加，请在未来的 KubeCon 上注册。并且，如果你遇到工作坊的与会者，请务必欢迎他们加入社区。 - 链接： - @@ -24,25 +24,25 @@ The Concepts section helps you learn about the parts of the Kubernetes system an {{% capture body %}} - ## 概述 - 要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。 - 一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器( PLEG )，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成： - ## Kubernetes 对象 Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。 - @@ -101,7 +101,7 @@ The various parts of the Kubernetes Control Plane, such as the Kubernetes Master 关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。 - @@ -119,25 +119,25 @@ The Kubernetes master is responsible for maintaining the desired state for your Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。 - > "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。 - ### Kubernetes Node 节点 - 集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。 - diff --git a/content/zh/docs/concepts/architecture/master-node-communication.md b/content/zh/docs/concepts/architecture/master-node-communication.md index 45b2d08d59..fe133d4b55 100644 --- a/content/zh/docs/concepts/architecture/master-node-communication.md +++ b/content/zh/docs/concepts/architecture/master-node-communication.md @@ -46,7 +46,7 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser 从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。 -默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。 +默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。 为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。 diff --git a/content/zh/docs/concepts/cluster-administration/certificates.md b/content/zh/docs/concepts/cluster-administration/certificates.md index 23d8e84133..234d97fc0a 100644 --- a/content/zh/docs/concepts/cluster-administration/certificates.md +++ b/content/zh/docs/concepts/cluster-administration/certificates.md @@ -40,7 +40,7 @@ manually through `easyrsa`, `openssl` or `cfssl`. tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki - + @@ -101,7 +101,7 @@ manually through `easyrsa`, `openssl` or `cfssl`. 1. 生成密钥位数为 2048 的 ca.key： openssl genrsa -out ca.key 2048 - + @@ -222,7 +222,7 @@ Finally, add the same parameters into the API server start parameters. chmod +x cfssljson curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo chmod +x cfssl-certinfo - + @@ -258,7 +258,7 @@ Finally, add the same parameters into the API server start parameters. } } } - + @@ -290,7 +290,7 @@ Finally, add the same parameters into the API server start parameters. 1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）： ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca - + 当前，如果有其他系统机制执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。 -比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。 +比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。 {{< /note >}} [cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh diff --git a/content/zh/docs/concepts/cluster-administration/proxies.md b/content/zh/docs/concepts/cluster-administration/proxies.md index 5ebaca61ed..49deadfd77 100644 --- a/content/zh/docs/concepts/cluster-administration/proxies.md +++ b/content/zh/docs/concepts/cluster-administration/proxies.md @@ -36,7 +36,7 @@ content_template: templates/concept - 在每个节点上运行 - 代理 UDP 和 TCP - - 不支持 HTTP + - 不支持 HTTP - 提供负载均衡能力 - 只用来访问 Service diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md index c8424c2d6f..ffa510620f 100644 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md @@ -383,7 +383,7 @@ with namespaces, it can prevent one team from hogging all the resources. 通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 -Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 +Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 [NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。 有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 @@ -484,7 +484,7 @@ If an optional runtime partition is used, root partition will not hold any image ## 本地临时存储 Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。 -在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 +在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。 该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。 @@ -553,7 +553,7 @@ spec: ### How Pods with ephemeral-storage requests are scheduled When you create a Pod, the Kubernetes scheduler selects a node for the Pod to -run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). +run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node. --> @@ -594,7 +594,7 @@ as alpha functionality for monitoring only. ### 监控临时存储消耗 使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。 -通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 +通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。 项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。 @@ -608,8 +608,8 @@ continues to consume space. This space will be tracked by the quota, but will not be seen by a directory scan. --> -配额比目录扫描更快，更准确。 -将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 +配额比目录扫描更快，更准确。 +将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。 -Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 +Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。 -在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 +在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 有关更多详细信息，请参见 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). {{< /note >}} @@ -854,7 +854,7 @@ _invalid_ quantities are `0.5` and `1500m`. ### 消耗扩展资源 -就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 +就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。 {{< note >}} @@ -948,7 +948,7 @@ consistency across providers and platforms. 在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量， 如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。 -在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 +在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 [资源类型](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/resources.md) 的框架。 Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168) 来支持资源的过度使用。 diff --git a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 5d5757ba5c..156cef644a 100644 --- a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -80,7 +80,7 @@ clusters and namespaces. A *context* element in a kubeconfig file is used to group access parameters under a convenient name. Each context has three parameters: cluster, namespace, and user. By default, the `kubectl` command-line tool uses parameters from -the *current context* to communicate with the cluster. +the *current context* to communicate with the cluster. ---> 通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。 @@ -156,7 +156,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: Even if the second file has non-conflicting entries under `red-user`, discard them. ---> 1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。 - + 否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件： * 忽略空文件名。 diff --git a/content/zh/docs/concepts/configuration/overview.md b/content/zh/docs/concepts/configuration/overview.md index abb90bde09..bb7f53f8c1 100644 --- a/content/zh/docs/concepts/configuration/overview.md +++ b/content/zh/docs/concepts/configuration/overview.md @@ -35,7 +35,7 @@ This is a living document. If you think of something that is not on this list bu --> - 在推送到集群之前，配置文件应存储在版本控制中。 这允许您在必要时快速回滚配置更改。 - 它还有助于集群重新创建和恢复。 + 它还有助于集群重新创建和恢复。 - *这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。 + *这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。 DNS没有此限制。 -在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。 +在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。 {{< /note >}} {{< note >}} diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md index 9e55499449..e889c0ffcc 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh/docs/concepts/configuration/secret.md @@ -121,8 +121,8 @@ If the password you are using has special characters, you need to escape them us kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb You do not need to escape special characters in passwords from files (`--from-file`). --> - - + + 特殊字符（例如 `$`, `\*` 和 `!` ）需要转义。 如果您使用的密码具有特殊字符，则需要使用 `\\` 字符对其进行转义。 例如，如果您的实际密码是 `S!B\*d$zDsb` ，则应通过以下方式执行命令： kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb @@ -376,9 +376,9 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if data和stringData的键必须由字母数字字符 '-', '_' 或者 '.' 组成。 -** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为base64字符串。 -换行符在这些字符串中无效，因此必须省略。 -在 Darwin / macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。 +** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为base64字符串。 +换行符在这些字符串中无效，因此必须省略。 +在 Darwin / macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。 相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0`， 或者，如果`-w`选项不可用的情况下， 执行 `base64 | tr -d '\n'`。 @@ -395,7 +395,7 @@ For example, to generate a Secret from files `./username.txt` and `./password.tx #### 从生成器创建 Secret Kubectl 从1.14版本开始支持 [使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/) -使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。 +使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。 生成器应在目录内的“ kustomization.yaml”中指定。 例如，从文件 `./username.txt` 和 `./password.txt` 生成一个 Secret。 @@ -953,7 +953,7 @@ field set to that of the service account. See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. --> - + ### 安排 imagePullSecrets 自动附加 您可以手动创建 imagePullSecret，并从 serviceAccount 引用它。使用该 serviceAccount 创建的任何 pod 和默认使用该 serviceAccount 的 pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 字段。有关该过程的详细说明，请参阅 [将 ImagePullSecrets 添加到服务帐户](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。 @@ -1141,7 +1141,7 @@ Make the kustomization.yaml with SecretGenerator 下面的例子说明一个 pod 消费一个包含 prod 凭据的 secret，另一个 pod 使用测试环境凭据消费 secret。 -通过秘钥生成器制作 kustomization.yaml +通过秘钥生成器制作 kustomization.yaml ```shell kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 diff --git a/content/zh/docs/concepts/configuration/taint-and-toleration.md b/content/zh/docs/concepts/configuration/taint-and-toleration.md index af4e054fe1..9314737cee 100755 --- a/content/zh/docs/concepts/configuration/taint-and-toleration.md +++ b/content/zh/docs/concepts/configuration/taint-and-toleration.md @@ -326,7 +326,7 @@ certain condition is true. The following taints are built in: this node, the kubelet removes this taint. --> 此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括： - + * `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。 * `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。 * `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。 diff --git a/content/zh/docs/concepts/containers/container-environment-variables.md b/content/zh/docs/concepts/containers/container-environment-variables.md index 6b84845df1..4cd656b9de 100644 --- a/content/zh/docs/concepts/containers/container-environment-variables.md +++ b/content/zh/docs/concepts/containers/container-environment-variables.md @@ -8,7 +8,7 @@ content_template: templates/concept {{% capture overview %}} -本文介绍容器环境中对容器可用的资源。 +本文介绍容器环境中对容器可用的资源。 {{% /capture %}} diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md index 3f4e6a8acd..3c5b73d69f 100644 --- a/content/zh/docs/concepts/containers/images.md +++ b/content/zh/docs/concepts/containers/images.md @@ -131,7 +131,7 @@ Docker将私有仓库的密钥存放在`$HOME/.dockercfg`或`$HOME/.docker/confi - 如果使用node IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` 1.将本地的`.docker/config.json`拷贝到每个节点root用户目录下 - 例如： `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done` - + 创建使用私有仓库的pod来验证，例如： ```yaml diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md index 5ad67c0270..6099164aca 100644 --- a/content/zh/docs/concepts/containers/runtime-class.md +++ b/content/zh/docs/concepts/containers/runtime-class.md @@ -8,14 +8,14 @@ weight: 20 {{< feature-state for_k8s_version="v1.14" state="beta" >}} - 这个文档主要说明了 RuntimeClass 资源和 kubernetes 指定容器运行时的功能。 {{< warning >}} - +--> 默认情况下，RuntimeClass 被假设为所有节点上的配置均为一致。(这意味着所有的 Node 节点的容器运行时必须以相同的方式进行设定)。 要支持不同配置构节点配置，请参见下面的[Scheduling]（＃scheduling）。 @@ -154,7 +154,7 @@ Once RuntimeClasses are configured for the cluster, using them is very simple. S --> ### 使用方法 -一旦集群中的 RuntimeClass 的设定完成，接下来的使用就变得非常简单了。只需要设定 PodSpec 的 `runtimeClassName` 设定项。 +一旦集群中的 RuntimeClass 的设定完成，接下来的使用就变得非常简单了。只需要设定 PodSpec 的 `runtimeClassName` 设定项。 例如： ```yaml @@ -220,7 +220,7 @@ Runtime handlers are configured through containerd's configuration at See containerd's config documentation for more details: https://github.com/containerd/cri/blob/master/docs/config.md --> -`containerd` 的具体设定请参考下面的文档信息。 +`containerd` 的具体设定请参考下面的文档信息。 https://github.com/containerd/cri/blob/master/docs/config.md #### [cri-o](https://cri-o.io/) @@ -230,7 +230,7 @@ Runtime handlers are configured through cri-o's configuration at `/etc/crio/crio handlers are configured under the [crio.runtime table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): --> -运行时处理程序通过cri-o的配置在 `/etc/crio/crio.conf` 中进行配置。 +运行时处理程序通过cri-o的配置在 `/etc/crio/crio.conf` 中进行配置。 有效的处理程序在[crio.runtime表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)下配置。 ``` @@ -266,13 +266,13 @@ the intersection of the set of nodes selected by each. If there is a conflict, t rejected. --> -从Kubernetes v1.16开始，RuntimeClass 通过 `scheduling` 字段添加了对异构集群的支持。 -通过使用这些字段，可以确保将与此 RuntimeClass一 起运行的 Pod 调度到支持它的节点上。 +从Kubernetes v1.16开始，RuntimeClass 通过 `scheduling` 字段添加了对异构集群的支持。 +通过使用这些字段，可以确保将与此 RuntimeClass一 起运行的 Pod 调度到支持它的节点上。 要使用计划支持，您必须启用 RuntimeClass [admission controller] []（默认值，自1.16开始）。 为了确保 Pod 被调度到支持特定 RuntimeClass 的节点上， -那组节点应该具有一个公共标签，然后由 `runtimeclass.scheduling.nodeSelector` 字段选择该标签。 -RuntimeClass 的 nodeSelector 在调度时与 Pod 的 nodeSelector 合并，有效地进行节点选择，并且调度到相应节点。 +那组节点应该具有一个公共标签，然后由 `runtimeclass.scheduling.nodeSelector` 字段选择该标签。 +RuntimeClass 的 nodeSelector 在调度时与 Pod 的 nodeSelector 合并，有效地进行节点选择，并且调度到相应节点。 如果有冲突，则将拒绝该 Pod 被调度。 聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。 @@ -26,7 +26,7 @@ The aggregation layer enables installing additional Kubernetes-style APIs in you 聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。 聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。 diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md index ffd10f75b5..b3b6a7b800 100644 --- a/content/zh/docs/concepts/overview/kubernetes-api.md +++ b/content/zh/docs/concepts/overview/kubernetes-api.md @@ -117,7 +117,7 @@ multiple API versions, each at a different API path, such as `/api/v1` or ## API 版本 为了使删除字段或者重构资源表示更加容易，Kubernetes 支持 -多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 +多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 `/apis/extensions/v1beta1`。 -使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 +使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令， 将 `.yaml` 文件作为参数。下面是一个示例： diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md index 93586739a3..756faeca12 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -33,12 +33,12 @@ need the features they provide. --> 命名空间为名称提供了一个范围。 -资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes +资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes 资源只能属于一个命名空间。 @@ -100,7 +100,7 @@ Kubernetes starts with three initial namespaces: * `kube-system` The namespace for objects created by the Kubernetes system * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. --> - + * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间 * `kube-system` Kubernetes 系统创建对象所使用的命名空间 * `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。 diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index 5054cb7f25..08e6a07f83 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -20,7 +20,7 @@ title: 资源配额 - 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额 约束的信息。 - 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request） - 和约束值（limit），否则配额系统将拒绝Pod的创建。 + 和约束值（limit），否则配额系统将拒绝Pod的创建。 提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。 作为示例，请参考 [演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) 来避免这个问题。 @@ -36,10 +36,10 @@ title: 资源配额 ## 启用资源配额 -资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的 +资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的 `--admission-control=` 参数中包含 `ResourceQuota` 时，资源配额会被启用。 -当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。 +当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。 一个namespace中最多只应存在一个 `ResourceQuota` 对象 ## 计算资源配额 diff --git a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 26b5f5a70b..dc442fcdf9 100644 --- a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -16,7 +16,7 @@ Modification not using HostAliases is not suggested because the file is managed 当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。 -建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。 +建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。 {{% /capture %}} {{% capture body %}} diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index 19df8fd369..6cec8b0ab5 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -22,7 +22,7 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same ## Kubernetes 连接容器模型 既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。 -在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。 +在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。 @@ -225,9 +225,9 @@ Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者 +too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` +flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). +--> 如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在 [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index ae53b2ca8f..fcd514a6c6 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -54,7 +54,7 @@ For more up-to-date specification, see 运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。 运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。 -以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。 +以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。 有关最新规范请查看 [Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md). @@ -145,7 +145,7 @@ Example: 在 v1.3 版本中，PodSpec 具有 `hostname` 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation `pod.beta.kubernetes.io/hostname`。 在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 `pod.beta.kubernetes.io/subdomain` 指定了 Pod 的子域名。 最终的域名将是 “...svc.”。 -举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。 +举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。 在 v1.3 版本中，PodSpec 具有 `subdomain` 字段，可以用来指定 Pod 的子域名。 这个字段的值优先于 annotation `pod.beta.kubernetes.io/subdomain` 的值。 @@ -235,7 +235,7 @@ record unless `publishNotReadyAddresses=True` is set on the Service. 因为没有为 Pod 名称创建A记录，所以要创建 Pod 的 A 记录需要 `hostname` 。 -没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。 +没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。 另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则 Pod 需要准备好 A 记录。 {{< /note >}} @@ -348,10 +348,10 @@ Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 --> - `nameservers`: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。 -- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 +- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 重复的域名将被删除。    Kubernetes最多允许6个搜索域。 -- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 +- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 重复的条目将被删除。 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 @@ -33,16 +33,16 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i ## 其他控制器 -* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress +* [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) 提供支持和维护. +* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护. * [Contour](https://github.com/heptio/contour) 是一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它由 Heptio 提供和支持。 * 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) 的企业级支持。 +* [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/)支持和维护。 @@ -76,9 +76,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i -在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。 +在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。 您需要确保创建包含 `sslexample.foo.com` 的 TLS 秘钥的 CN 的证书。 ```yaml @@ -528,7 +528,7 @@ platform specific Ingress controller to understand how TLS works in your environ 各种 Ingress 控制器所支持的 TLS 功能之间存在间隙。请参阅有关文件 [nginx](https://git.k8s.io/ingress-nginx/README.md#https)， -[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)， +[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)， 或任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。 {{< /note >}} @@ -681,7 +681,7 @@ for details on deploying Ingress in a federated cluster. ## 跨可用区失败 用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。 -请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 +请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 您还可以参考[联合文档](/docs/concepts/cluster-administration/federation/)，以获取有关在联合群集中部署Ingress的详细信息。 @@ -696,7 +696,7 @@ evolution of various Ingress controllers. ## 未来的工作 -跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。 +跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。 您也可以跟踪 [Ingress信息库](https://github.com/kubernetes/ingress/tree/master) 了解 Ingress 控制器进化的更多信息。 -Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。 +Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。 这为部署和发展服务提供了很大的灵活性。 例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。 @@ -306,7 +306,7 @@ endpoints. Endpoint Slices provide additional attributes and functionality which is described in detail in [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/). --> -Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。 +Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。 默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。 @@ -345,7 +345,7 @@ There are a few reasons for using proxying for Services: ### 为什么不使用 DNS 轮询？ -时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ +时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ 例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？ 使用服务代理有以下几个原因： @@ -504,7 +504,7 @@ falls back to running in iptables proxy mode. 要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS Linux 在节点上可用。 -当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 +当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。 {{< /note >}} @@ -699,7 +699,7 @@ You can find more information about `ExternalName` resolution in 您可以（几乎总是应该）使用[附加组件](/docs/concepts/cluster-administration/addons/)为Kubernetes集群设置DNS服务。 -支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 +支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。 例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务， @@ -708,7 +708,7 @@ You can find more information about `ExternalName` resolution in 其他命名空间中的Pod必须将名称限定为 `my-service.my-ns` 。 这些名称将解析为为服务分配的群集IP。 -Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 +Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为`TCP`， 则可以对 `_http._tcp.my-service.my-ns` 执行DNS SRV查询查询以发现该端口号, `"http"`以及IP地址。 @@ -888,7 +888,7 @@ For example: 使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。 负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。 -实例: +实例: ```yaml apiVersion: v1 @@ -945,10 +945,10 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357). --> -在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。 +在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。 此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。 -将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。 +将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息， 请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 {{< /note >}} @@ -1245,7 +1245,7 @@ also be used to set maximum time, in seconds, to keep the existing connections o #### AWS上的连接排空 -可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。 +可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。 注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。 ```yaml @@ -1388,7 +1388,7 @@ public IP addresses, be aware that non-NLB traffic can also reach all instances in those modified security groups. --> -如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。 +如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。 如果节点具有公共 IP 地址，请注意，非 NLB 流量也可以到达那些修改后的安全组中的所有实例。 {{< /note >}} @@ -1404,7 +1404,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`: ### 类型ExternalName {#externalname} -类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。 +类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。 您可以使用 `spec.externalName` 参数指定这些服务。 例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`： @@ -1427,7 +1427,7 @@ is intended to specify a canonical DNS name. To hardcode an IP address, consider [headless Services](#headless-services). --> -ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 +ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 要对 IP 地址进行硬编码，请考虑使用 [headless Services](#headless-services)。 {{< /note >}} @@ -1442,7 +1442,7 @@ Service's `type`. --> 当查找主机 `my-service.prod.svc.cluster.local` 时，群集DNS服务返回 `CNAME` 记录，其值为 `my.database.example.com`。 -访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 +访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的`类型`。 {{< note >}} @@ -1772,10 +1772,10 @@ Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPoli When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections. --> -Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。 +Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。 要启用此功能，集群管理员需要在apiserver上启用 `SCTPSupport` 功能门，例如 `--feature-gates = SCTPSupport = true，…`。 -启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。 +启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。 Kubernetes相应地为 SCTP 关联设置网络，就像为 TCP 连接一样。 `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。 - 2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。 @@ -942,8 +942,8 @@ parameters: When `kind` is `shared`, all unmanaged disks are created in a few shared storage accounts in the same resource group as the cluster. When `kind` is `dedicated`, a new dedicated storage account will be created for the new - unmanaged disk in the same resource group as the cluster. When `kind` is - `managed`, all managed disks are created in the same resource group as + unmanaged disk in the same resource group as the cluster. When `kind` is + `managed`, all managed disks are created in the same resource group as the cluster. --> * `storageaccounttype`：Azure 存储帐户 Sku 层。默认为空。 @@ -985,12 +985,12 @@ parameters: group are searched to find one that matches `skuName` and `location`. If a storage account is provided, it must reside in the same resource group as the cluster, and `skuName` and `location` are ignored. -* `secretNamespace`: the namespace of the secret that contains the Azure Storage +* `secretNamespace`: the namespace of the secret that contains the Azure Storage Account Name and Key. Default is the same as the Pod. * `secretName`: the name of the secret that contains the Azure Storage Account Name and Key. Default is `azure-storage-account--secret` * `readOnly`: a flag indicating whether the storage will be mounted as read only. - Defaults to false which means a read/write mount. This setting will impact the + Defaults to false which means a read/write mount. This setting will impact the `ReadOnly` setting in VolumeMounts as well. --> * `skuName`：Azure 存储帐户 Sku 层。默认为空。 @@ -1003,9 +1003,9 @@ parameters: * `readOnly`：指示是否将存储安装为只读的标志。默认为 false，表示 读/写 挂载。 该设置也会影响VolumeMounts中的 `ReadOnly` 设置。 diff --git a/content/zh/docs/concepts/storage/storage-limits.md b/content/zh/docs/concepts/storage/storage-limits.md index 9b077d9d41..5009530e9a 100644 --- a/content/zh/docs/concepts/storage/storage-limits.md +++ b/content/zh/docs/concepts/storage/storage-limits.md @@ -5,28 +5,28 @@ content_template: templates/concept {{% capture overview %}} - 此页面描述了各个云供应商可关联至一个节点的最大卷数。 - -谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 +谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 Kubernetes 需要尊重这些限制。 否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。 {{% /capture %}} {{% capture body %}} - @@ -80,7 +80,7 @@ The limit applies to the entire cluster, so it affects all Nodes. {{< feature-state state="beta" for_k8s_version="v1.12" >}} - - + ### 快照生成器（Snapshotter） 卷快照类具有一个快照生成器，用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。 - -阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 +阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 {{% /capture %}} @@ -473,7 +473,7 @@ It mounts a directory and writes the requested data in plain text files. --> `downwardAPI` 卷用于使 downward API 数据对应用程序可用。 -这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 +这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 {{< note >}} @@ -1149,7 +1149,7 @@ guide](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). 您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 请注意，此驱动不支持动态配置。 -有关如何运行外部 `local` 卷驱动的示例，请参考 +有关如何运行外部 `local` 卷驱动的示例，请参考 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。 {{< note >}} @@ -1502,7 +1502,7 @@ means that a RBD volume can be pre-populated with data, and that data can be "handed off" between Pods. --> -`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. +`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 @@ -1734,7 +1734,7 @@ You must create VMDK using one of the following methods before using with Pod. Choose one of the following methods to create a VMDK. --> -#### 创建 VMDK 卷 +#### 创建 VMDK 卷 选择下列方式之一创建 VMDK。 @@ -2086,7 +2086,7 @@ persistent volume: - `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应；[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 - + - + - `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 此字段是可选的，如果不需要 secret，则可能是空的。 如果 secret 对象包含多个 secret，则传递所有 secret。 @@ -2308,9 +2308,9 @@ Its values are: [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) --> * `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 - + 换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。 - + 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rslave` 挂载传播选项。 diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index 43f67cb87b..7f8a9e2f91 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -159,7 +159,7 @@ Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决 和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。 关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、 -[配置容器](/docs/user-guide/configuring-containers) 和 +[配置容器](/docs/user-guide/configuring-containers) 和 [使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。 Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md index 60822051ba..2d7a49c509 100644 --- a/content/zh/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md @@ -16,7 +16,7 @@ redirect_from: _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。 - + 使用 DaemonSet 的一些典型用法： diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index bf4eadca5c..6b3537441b 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh/docs/concepts/workloads/pods/init-containers.md @@ -188,7 +188,7 @@ pod "myapp-pod" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m -$ kubectl describe -f myapp.yaml +$ kubectl describe -f myapp.yaml Name: myapp-pod Namespace: default [...] @@ -268,7 +268,7 @@ Init 容器的端口将不会在 Service 中进行聚集。 特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。 Init 容器具有应用容器的所有字段。 -然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。 +然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。 这会在验证过程中强制执行。 diff --git a/content/zh/docs/concepts/workloads/pods/podpreset.md b/content/zh/docs/concepts/workloads/pods/podpreset.md index 81b9f5d4db..cce548b0a3 100644 --- a/content/zh/docs/concepts/workloads/pods/podpreset.md +++ b/content/zh/docs/concepts/workloads/pods/podpreset.md @@ -25,7 +25,7 @@ pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。 ## PodPreset 如何工作 -Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset +Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset 应用于接收到的 pod 创建请求中。 当出现 pod 创建请求时，系统会执行以下操作： @@ -36,9 +36,9 @@ Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时， 1. 为改动的 pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如： `podpreset.admission.kubernetes.io/podpreset-": ""`。 -一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` +一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` 可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes -修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod +修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod 中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。 {{< note >}} diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index d855803396..c110f90794 100755 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -229,19 +229,19 @@ An example request body: 请求载荷例子： ``` -{ +{ "apiVersion":"imagepolicy.k8s.io/v1alpha1", "kind":"ImageReview", - "spec":{ - "containers":[ - { + "spec":{ + "containers":[ + { "image":"myrepo/myimage:v1" }, - { + { "image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed" } ], - "annotations":[ + "annotations":[ "mycluster.image-policy.k8s.io/ticket-1234": "break-glass" ], "namespace":"mynamespace" @@ -510,7 +510,7 @@ for more information. 这个插件限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个入场插件的限制，kubelet 必须在 `system：nodes` 组中使用凭证，并使用 `system：node：` 形式的用户名。这样的 kubelet 只允许修改自己的 `Node` API 对象，只能修改绑定到节点本身的 `Pod` 对象。 diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md index 8ca313af01..c953e33cc3 100644 --- a/content/zh/docs/reference/access-authn-authz/authorization.md +++ b/content/zh/docs/reference/access-authn-authz/authorization.md @@ -109,7 +109,7 @@ DELETE | delete (for individual resources), deletecollection (for collections Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example: * [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group. -* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization +* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group. * [Authentication](/docs/reference/access-authn-authz/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group. --> @@ -141,7 +141,7 @@ Kubernetes有时使用专门的动词检查授权以获得额外的权限。例 * To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. * **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/). --> - + ## 授权模块 * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/). * **ABAC** - 基于属性的访问控制（ABAC) 定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅[ABAC 模式](/docs/reference/access-authn-authz/abac/)。 @@ -169,7 +169,7 @@ yes $ kubectl auth can-i create deployments --namespace prod no ``` - diff --git a/content/zh/docs/reference/access-authn-authz/controlling-access.md b/content/zh/docs/reference/access-authn-authz/controlling-access.md index 251b69484d..19831ea749 100644 --- a/content/zh/docs/reference/access-authn-authz/controlling-access.md +++ b/content/zh/docs/reference/access-authn-authz/controlling-access.md @@ -73,7 +73,7 @@ Bootstrap Tokens，以及JWT Tokens (用于服务账户)。 } } ``` -如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。 +如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。 Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的，因为除Kubernetes外，这些访问控制系统还可能与其他的API进行交互。 @@ -103,7 +103,7 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook ## API的端口和IP -上述讨论适用于发送请求到API服务器的安全端口(典型情况)。 +上述讨论适用于发送请求到API服务器的安全端口(典型情况)。 实际上API服务器可以通过两个端口提供服务： 默认情况下，API服务器在2个端口上提供HTTP服务： diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md index bf3e0783f9..f8ad257203 100644 --- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -7,7 +7,7 @@ approvers: title: 管理Service Accounts --- -*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。* +*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。* *对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述service accounts，有时这些不完善的特性也会被提及。* diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md index 53b9836812..061865f7db 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -49,15 +49,15 @@ kube-apiserver --authentication-token-webhook-config-file string 包含webhook配置的文件，用于令牌认证，具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。 --authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值"AlwaysAllow"） - + --authorization-policy-file string 包含权限验证策略的csv文件，和--authorization-mode=ABAC一起使用，作用在安全端口上。 - - --authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s） - + + --authorization-webhook-cache-authorized-ttl duration 从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s） + --authorization-webhook-cache-unauthorized-ttl duration 从webhook授权者获得的'unauthorized'响应的缓存时长。（默认值30s） - + --authorization-webhook-config-file string 包含webhook配置的kubeconfig格式文件，和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。 - + --azure-container-registry-config string 包含Azure容器注册表配置信息的文件的路径。 --basic-auth-file string 如果设置该值，这个文件将会被用于准许通过http基本认证到API server安全端口的请求。 @@ -67,11 +67,11 @@ kube-apiserver --cert-dir string 存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项，该标志将被忽略。（默认值 "/var/run/kubernetes"） --client-ca-file string 如果设置此标志，对于任何请求，如果存包含client-ca-file中的authorities签名的客户端证书，将会使用客户端证书中的CommonName对应的身份进行认证。 - + --cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件. - + --cloud-provider string 云服务提供商，空字符串表示无提供商。 - + --contention-profiling 如果已经启用profiling，则启用锁竞争profiling。 --cors-allowed-origins stringSlice CORS的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS. @@ -148,12 +148,12 @@ TaintBasedEvictions=true|false (ALPHA - default=false) --kubelet-read-only-port uint 已废弃: kubelet端口. （默认值10255） - --kubelet-timeout duration kubelet操作超时时间。（默认值 + --kubelet-timeout duration kubelet操作超时时间。（默认值 5s） --kubernetes-service-node-port int 如果不为0，Kubernetes master服务（用于创建/管理apiserver）将会使用NodePort类型，并将这个值作为端口号。如果为0，Kubernetes master服务将会使用ClusterIP类型。 - --master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"） + --master-service-namespace string 已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"） --max-connection-bytes-per-sec int 如果不为0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。 @@ -162,67 +162,67 @@ TaintBasedEvictions=true|false (ALPHA - default=false) --max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值400） --min-request-timeout int 一个可选字段，表示一个handler在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值1800）。 - + --oidc-ca-file string 如果设置该值，将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证，否则将会使用主机的根CA对其进行验证。 - + --oidc-client-id string 使用OpenID连接的客户端的ID，如果设置了oidc-issuer-url，则必须设置这个值。 - + --oidc-groups-claim string 如果提供该值，这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。 --oidc-issuer-url string OpenID颁发者URL，只接受HTTPS方案。如果设置该值，它将被用于验证OIDC JSON Web Token(JWT)。 - + --oidc-username-claim string 用作用户名的OpenID声明值。注意，不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。 - + --profiling 在web接口host:port/debug/pprof/上启用profiling。（默认值true） - + --proxy-client-cert-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。 - + --proxy-client-key-file string 当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。 - + --repair-malformed-updates 如果为true，服务将会尽力修复更新请求以通过验证，例如：将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。 --requestheader-allowed-names stringSlice 使用--requestheader-username-headers指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。 - + --requestheader-client-ca-file string 在信任请求头中以--requestheader-username-headers指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。 - + --requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。 --requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用X-Remote-Group. - + --requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用X-Remote-User。 - + --runtime-config mapStringString 传递给apiserver用于描述运行时配置的键值对集合。 apis/键可以被用来打开/关闭特定的api版本。apis//键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本. - + --secure-port int 用于监听具有认证授权功能的HTTPS协议的端口。如果为0，则不会监听HTTPS协议。 （默认值6443) - + --service-account-key-file stringArray 包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件，用于验证ServiceAccount令牌。如果设置该值，--tls-private-key-file将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。 - + --service-cluster-ip-range ipNet CIDR表示的IP范围，服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。 - + --ssh-keyfile string 如果不为空，在使用安全的SSH代理访问节点时，将这个文件作为用户密钥文件。 - + --storage-backend string 持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'. - + --storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型，并且忽略该配置项。（默认值 "application/vnd.kubernetes.protobuf") - + --storage-versions string 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来，所有注册组的首选版本列表。 （默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1") - + --target-ram-mb int apiserver内存限制，单位为MB(用于配置缓存大小等)。 - + --tls-ca-file string 如果设置该值，这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中. - + --tls-cert-file string 包含用于HTTPS的默认x509证书的文件。（如果有CA证书，则附加于server证书之后）。如果启用了HTTPS服务，并且没有提供--tls-cert-file和--tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。 - + --tls-private-key-file string 包含匹配--tls-cert-file的x509证书私钥的文件。 - + --tls-sni-cert-key namedCertKey 一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[]) - + --token-auth-file string 如果设置该值，这个文件将被用于通过令牌认证来保护API服务的安全端口。 - + --version version[=true] 打印版本信息并退出。 - + --watch-cache 启用apiserver的监视缓存。（默认值true） - + --watch-cache-sizes stringSlice 每种资源（pods, nodes等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size是一个数字。在watch-cache启用时生效。 ``` diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 92c3b2270c..052b09e313 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -27,7 +27,7 @@ While any authentication strategy can be used for the kubelet's initial bootstra 1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__ 2. [Token authentication file](###token-authentication-file) -Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario. +Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario. ### Token authentication file Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number diff --git a/content/zh/docs/reference/glossary/ingress.md b/content/zh/docs/reference/glossary/ingress.md index 1f5beff121..c06726c68f 100755 --- a/content/zh/docs/reference/glossary/ingress.md +++ b/content/zh/docs/reference/glossary/ingress.md @@ -6,7 +6,7 @@ full_link: /docs/concepts/services-networking/ingress/ short_description: > An API object that manages external access to the services in a cluster, typically HTTP. -aka: +aka: tags: - networking - architecture @@ -17,7 +17,7 @@ tags: --> 一个 API 对象，用于管理对集群中服务的外部访问，通常是 HTTP。 - + diff --git a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md index e1bee1f55d..63228cd528 100644 --- a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -20,7 +20,7 @@ $ docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 ngi a9ec34d9878748d2f33dc20cb25c714ff21da8d40558b45bfaec9955859075d0 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx-app +a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx-app ``` 使用 kubectl 命令： @@ -141,7 +141,7 @@ $ docker exec -ti a9ec34d98787 /bin/sh 使用 kubectl 命令： ```shell -$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh +$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` diff --git a/content/zh/docs/reference/kubectl/kubectl.md b/content/zh/docs/reference/kubectl/kubectl.md index 81f971e94e..a2a372edf4 100644 --- a/content/zh/docs/reference/kubectl/kubectl.md +++ b/content/zh/docs/reference/kubectl/kubectl.md @@ -12,7 +12,7 @@ kubectl 可以操控 Kubernetes 集群。 diff --git a/content/zh/docs/reference/kubernetes-api/_index.md b/content/zh/docs/reference/kubernetes-api/_index.md index bb959eb924..0d9b907899 100644 --- a/content/zh/docs/reference/kubernetes-api/_index.md +++ b/content/zh/docs/reference/kubernetes-api/_index.md @@ -1,4 +1,4 @@ --- -title: Kubernetes API +title: Kubernetes API weight: 30 --- diff --git a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md index fbeffb9587..52b704b6bb 100644 --- a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md +++ b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md @@ -70,25 +70,25 @@ Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。 未使 用于：节点、PersistentVolume -用于节点： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。 未使用 `cloudprovider` +用于节点： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。 未使用 `cloudprovider` 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。 用于 PersistentVolume：在 GCE 和 AWS 中，`PersistentVolumeLabel` 准入控制器会自动添加区域标签。 -在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。 -在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。 跨区分散通过 SelectorSpreadPriority +在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。 +在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。 跨区分散通过 SelectorSpreadPriority 来实现。 这是一种尽力而为（best-effort）的处置方式， 如果集群中的区域是异构的 (例如：不同区域之间的节点数量、 -节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域 +节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域 (节点数量和类型相同) 来减小 pod 分布不均的可能性。 -由于卷不能跨区域挂载（attach），调度器 (通过 VolumeZonePredicate 断言) 也会保证需要特定卷的 pod +由于卷不能跨区域挂载（attach），调度器 (通过 VolumeZonePredicate 断言) 也会保证需要特定卷的 pod 被调度到卷所在的区域中。 区域和地域（region）的实际值无关紧要，两者的层次含义也没有严格的定义。 最终期望是，除非整个地域故障， -否则某一区域节点的故障不应该影响到其他区域的节点。 例如，通常区域间应该避免共用同一个网络交换机。 +否则某一区域节点的故障不应该影响到其他区域的节点。 例如，通常区域间应该避免共用同一个网络交换机。 具体的规划取决于特定的基础设备—— three-rack 设备所选择的设置与多数据中心截然不同。 如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 4db61886dd..ff704dda56 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -79,7 +79,7 @@ following steps: --> themselves with the master in the future. Optionally, the user can provide a token via `--token`, as described in the [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) docs. --> -3. 生成令牌以便其它节点以后可以使用这个令牌向 master 节点注册它们自己。 可选的，用户可以通过 `--token` 提供一个令牌, 正如文档[kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。 +3. 生成令牌以便其它节点以后可以使用这个令牌向 master 节点注册它们自己。 可选的，用户可以通过 `--token` 提供一个令牌, 正如文档[kubeadm 的令牌](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 描述的那样。 [`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。 -## Kubeadm +## Kubeadm -[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。 +[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。 ## Helm diff --git a/content/zh/docs/setup/independent/create-cluster-kubeadm.md b/content/zh/docs/setup/independent/create-cluster-kubeadm.md index 0648f32972..f4d18d63be 100644 --- a/content/zh/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/zh/docs/setup/independent/create-cluster-kubeadm.md @@ -15,13 +15,13 @@ weight: 30 {{% capture overview %}} **kubeadm** 能帮助您建立一个小型的符合最佳实践的 Kubernetes 集群。通过使用 kubeadm, 您的集群会符合 [Kubernetes 合规性测试](https://kubernetes.io/blog/2017/10/software-conformance-certification)的要求. Kubeadm 也支持其他的集群生命周期操作，比如升级、降级和管理[启动引导令牌](/docs/reference/access-authn-authz/bootstrap-tokens/)。 - 因为您可以在不同类型的机器（比如笔记本、服务器和树莓派等）上安装 kubeadm，因此它非常适合与 Terraform 或 Ansible 这类自动化管理系统集成。 @@ -129,7 +129,7 @@ Kubernetes 发现版本的通常只维护支持九个月，在维护周期内， {{% /capture %}} {{% capture prerequisites %}} - ## 步骤 -### 在您的机器上安装 kubeadm +### 在您的机器上安装 kubeadm 请查阅[安装 kubeadm](/docs/setup/independent/install-kubeadm/)。 @@ -198,22 +198,22 @@ communicates with). --> 主节点是集群里运行控制面的机器，包括 etcd (集群的数据库)和 API 服务（kubectl CLI 与之交互）。 - @@ -227,7 +227,7 @@ IPv6 的集群，则需要指定一个 IPv6 地址，比如 `--apiserver-adverti 现在运行: ```bash -kubeadm init +kubeadm init ``` 如果需要再次运行 `kubeadm init`，您必须先[卸载集群](#tear-down)。 @@ -383,8 +383,8 @@ each other. --> kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).** Several projects provide Kubernetes Pod networks using CNI, some of which also -support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons. -- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). +support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons. +- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). - [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9. --> **网络必须在部署任何应用之前部署好。此外，在网络安装之前是 CoreDNS 不会启用的。 @@ -524,7 +524,7 @@ kubectl create -f ./ {{% /tab %}} - {{% capture overview %}} - * 一台或多台运行着下列系统的机器: - Ubuntu 16.04+ @@ -49,7 +49,7 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust - HypriotOS v1.0.1+ - Container Linux (针对1800.6.0 版本测试) * 每台机器 2 GB 或更多的 RAM (如果少于这个数字将会影响您应用的运行内存) -* 2 CPU 核心或更多 +* 2 CPU 核心或更多 * 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以) * 节点之中不可以有重复的主机名，MAC 地址，product_uuid。更多详细信息请参见[这里](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) 。 * 开启主机上的一些特定端口. 更多详细信息请参见[这里](#check-required-ports)。 @@ -59,8 +59,8 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust {{% capture steps %}} - ## 确保每个节点上 MAC 地址和 product_uuid 的唯一性。 @@ -71,11 +71,11 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust * 您可以使用下列命令获取网络接口的 MAC 地址：`ip link` 或是 `ifconfig -a` * 下列命令可以用来获取 product_uuid `sudo cat /sys/class/dmi/id/product_uuid` - 一般来讲，硬件设备会拥有独一无二的地址，但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一，可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。 @@ -128,15 +128,15 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t ** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。 - 任何使用 * 标记的端口号都有可能被覆盖，所以您需要保证您的自定义端口的状态是开放的。 - 虽然主节点已经包含了 etcd 的端口，您也可以使用自定义的外部 etcd 集群，或是指定自定义端口。 ## 安装 runtime - 从 v1.6.0 起，Kubernetes 开始允许使用 CRI，容器运行时接口。默认的容器运行时是 Docker，这是由 `kubelet` 内置的 CRI 实现 `dockershim` 开启的。 - 其他的容器运行时有： @@ -171,8 +171,8 @@ Other CRI-based runtimes include: - [frakti](https://github.com/kubernetes/frakti) - [rkt](https://github.com/kubernetes-incubator/rktlet) - 参考 [CRI 安装指南](/docs/setup/cri) 获取更多信息. @@ -181,7 +181,7 @@ Refer to the [CRI installation instructions](/docs/setup/cri) for more informati --> ## 安装 kubeadm, kubelet 和 kubectl - 您需要在每台机器上都安装以下的软件包： * `kubeadm`: 用来初始化集群的指令。 - + * `kubelet`: 在集群中的每个节点上用来启动 pod 和 container 等。 - + * `kubectl`: 用来与集群通信的命令行工具。 - kubeadm **不能** 帮您安装或管理 `kubelet` 或 `kubectl` ，所以您得保证他们满足通过 kubeadm 安装的 Kubernetes 控制层对版本的要求。如果版本没有满足要求，就有可能导致一些难以想到的错误或问题。然而控制层与 kubelet 间的 _小版本号_ 不一致无伤大雅，不过请记住 kubelet 的版本不可以超过 API server 的版本。例如 1.8.0 的 API server 可以适配 1.7.0 的 kubelet，反之就不行了。 - {{< warning >}} 这些指南不包括所有系统升级时使用的 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 需要 [升级时的特别注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)。 -{{}} +{{}} - 更多关于版本偏差的信息，请参阅 [版本偏差政策](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)。 {{< tabs name="k8s_install" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} ```bash apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - @@ -271,12 +271,12 @@ systemctl enable kubelet && systemctl start kubelet **请注意：** - - 通过命令 `setenforce 0` 和 `sed ...` 可以将 SELinux 设置为 permissive 模式(将其禁用)。 只有执行这一操作之后，容器才能访问宿主的文件系统，进而能够正常使用 Pod 网络。您必须这么做，直到 kubelet 做出升级支持 SELinux 为止。 @@ -303,10 +303,10 @@ mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` - -安装 crictl (kubeadm / Kubelet 的容器运行时接口 (CRI) 要求) +安装 crictl (kubeadm / Kubelet 的容器运行时接口 (CRI) 要求) ```bash CRICTL_VERSION="v1.11.1" @@ -314,7 +314,7 @@ mkdir -p /opt/bin curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz ``` - 安装 `kubeadm`, `kubelet`, `kubectl` 并且添加一个 `kubelet` systemd 服务: @@ -332,8 +332,8 @@ mkdir -p /etc/systemd/system/kubelet.service.d curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` - 启用并启动 `kubelet`: @@ -391,19 +391,19 @@ systemctl daemon-reload systemctl restart kubelet ``` - ## 查错 - -如果您在使用 kubeadm 时候遇到问题，请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/). +如果您在使用 kubeadm 时候遇到问题，请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/). {{% capture whatsnext %}} - -* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) +* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) {{% /capture %}} diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md index 10b68fbed3..54fed8a661 100644 --- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md @@ -313,7 +313,7 @@ such as your desktop machine. --> ## 访问集群中正在运行的服务 -上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。 +上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。 在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。 在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。 @@ -499,14 +499,14 @@ The redirect capabilities have been deprecated and removed. Please use a proxy There are several different proxies you may encounter when using Kubernetes: 1. The [kubectl proxy](#directly-accessing-the-rest-api): - + - runs on a user's desktop or in a pod - proxies from a localhost address to the Kubernetes apiserver - client to proxy uses HTTP - proxy to apiserver uses HTTPS - locates apiserver - adds authentication headers - + --> ## 多种代理 @@ -520,10 +520,10 @@ There are several different proxies you may encounter when using Kubernetes: - 代理到 apiserver 使用 HTTPS - 定位 apiserver - 添加身份验证 header - + 1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)： - + - 运行在每个节点上 - 代理 UDP 和 TCP - 不能代理 HTTP - 提供负载均衡 - 只能用来访问服务 - + 1. 位于 apiserver 之前的 Proxy/Load-balancer： - + - 存在和实现因集群而异（例如 nginx） - 位于所有客户和一个或多个 apiserver 之间 - 如果有多个 apiserver，则充当负载均衡器 - + 1. 外部服务上的云负载均衡器： - + - 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer） - 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建 - 只使用 UDP/TCP diff --git a/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md index 79aeae2edc..a23cea7633 100644 --- a/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md +++ b/content/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md @@ -9,7 +9,7 @@ weight: 90 {{% capture overview %}} - * 因为在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的 服务发送数据包。 - - * 最后你又虚拟机上的80端口启动 nginx 服务器（ip地址2.3.4.5）。 这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了互联网上。 - + Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。 {{% /capture %}} diff --git a/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md index b653c5aecb..d938225a66 100644 --- a/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md +++ b/content/zh/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md @@ -57,7 +57,7 @@ load-balanced access to an application running in a cluster. ``` kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 ``` - + @@ -99,7 +99,7 @@ load-balanced access to an application running in a cluster. ``` kubectl get services example-service ``` - + 当 pod 是 ready 时，您将得到： - + kubectl get pods NAME READY STATUS RESTARTS AGE redis-master-765d459796-258hz 1/1 Running 0 50s kubectl get deployment - + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE redis-master 1 1 1 1 55s kubectl get rs - + NAME DESIRED CURRENT READY AGE redis-master-765d459796 1 1 1 1m @@ -104,9 +104,9 @@ for database debugging. --> 3. 验证 Redis 服务是否运行在 pod 中并且监听 6379 端口： - + kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' - + 或者 - kubectl port-forward deployment/redis-master 6379:6379 + kubectl port-forward deployment/redis-master 6379:6379 或者 - kubectl port-forward rs/redis-master 6379:6379 + kubectl port-forward rs/redis-master 6379:6379 设置一个扩展的 API server 来使用聚合层以让 Kubernetes apiserver 使用其它 API 进行扩展，这些 API 不是核心 Kubernetes API 的一部分。 diff --git a/content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md b/content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md index 3f94a633ad..3a08f4d5a7 100644 --- a/content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md +++ b/content/zh/docs/tasks/administer-cluster/apply-resource-quota-limit.md @@ -333,7 +333,7 @@ deployment "not-best-effort-nginx" created ``` -虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。 +虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。 让我们列出 namespace 中的 pods： @@ -384,7 +384,7 @@ requests.memory 512Mi 1Gi ``` -如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。 +如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。 Scopes 提供了一种来对任何配额文档追踪的资源集合进行细分的机制，给操作人员部署和追踪资源消耗带来更大的灵活性。 diff --git a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md index fe419be70b..c497a26ae2 100644 --- a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md @@ -55,7 +55,7 @@ content_template: templates/task 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。 - 要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`： + 要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`： kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' diff --git a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index eaccecc135..428845923c 100644 --- a/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -30,7 +30,7 @@ content_template: templates/task 1. 列出你集群中的 PersistentVolumes kubectl get pv - + 输出类似于这样： NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE @@ -47,7 +47,7 @@ content_template: templates/task ```shell kubectl patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' ``` - + 这里的 `` 是你选择的 PersistentVolume 的名字。 3. 验证你选择的 PersistentVolume 拥有正确的策略： diff --git a/content/zh/docs/tasks/administer-cluster/cluster-management.md b/content/zh/docs/tasks/administer-cluster/cluster-management.md index 2b88c784e0..0e4c3393de 100644 --- a/content/zh/docs/tasks/administer-cluster/cluster-management.md +++ b/content/zh/docs/tasks/administer-cluster/cluster-management.md @@ -15,7 +15,7 @@ title: 集群管理 ## 创建和配置集群 -要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/) +要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/) ## 升级集群 diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index 0fe49f3db2..30798bb20b 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -38,7 +38,7 @@ content_template: templates/task ```console $ kubectl run nginx --image=nginx --replicas=2 deployment "nginx" created -$ kubectl expose deployment nginx --port=80 +$ kubectl expose deployment nginx --port=80 service "nginx" exposed ``` @@ -121,7 +121,7 @@ Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending Hit enter for command prompt -/ # wget --spider --timeout=1 nginx +/ # wget --spider --timeout=1 nginx Connecting to nginx (10.100.0.16:80) wget: download timed out / # diff --git a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md index d9b2d75887..46edad2d84 100644 --- a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -95,7 +95,7 @@ data: 1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。 1. 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上： - + * *具有集群后缀的名字*（例如 ".cluster.local"）：请求被发送到 kube-dns。 * *具有存根域后缀的名字*（例如 ".acme.local"）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。 diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md index 6cde6e07cc..f0db5e13ba 100644 --- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9.md @@ -4,7 +4,7 @@ reviewers: - luxas - roberthbailey - jbeda -title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级 +title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级 content_template: templates/task --- @@ -98,9 +98,9 @@ chmod a+rx /usr/bin/kubeadm {{< caution >}} **注意:** 在您的系统上升级控制面板之前升级 `kubeadm` 包会导致升级失败。 @@ -189,7 +189,7 @@ You can now apply the upgrade by executing the following command: _____________________________________________________________________ ``` - + ---> ```shell @@ -242,7 +242,7 @@ _____________________________________________________________________ 请注意：在您执行升级之前，您必须升级 kubeadm 到 v1.9.0 版本 _____________________________________________________________________ ``` - + - + 升级具有默认内部的 DNS 的 coreDNS 集群，调用具有 `--feature-gates=CoreDNS=true` 标记的 `kubeadm upgrade apply`。 `kubeadm upgrade apply`按照如下进行： @@ -345,14 +345,14 @@ To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional upgrade steps necessary. - + ---> 4. 手动升级定义网络（SDN）的软件 容器网络接口（CNI）提供者具有升级说明指导。 检查这个[插件](/docs/concepts/cluster-administration/addons/)页面来找到 CNI 提供者和查看是否需要额外的升级步骤。 - + * 运行在命名空间中的每个容器必须有自己的内存限制。 -* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。 +* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。 ## 使用 kubeadm 创建一个本地 Calico 集群 -在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考 +在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考 [Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。 {{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 61be3718b3..65cc53055c 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -24,7 +24,7 @@ For background on Cilium, read the [Introduction to Cilium](https://cilium.readt {{% /capture %}} {{% capture steps %}} - 入门指南其余的部分用一个示例应用说明了如何强制执行L3/L4（即 IP 地址+端口）的安全策略以及L7 （如 HTTP）的安全策略。 - Romana 安装完成后，您可以按照[声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 Kubernetes NetworkPolicy。 diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 26eb7434ba..8b1a5d3163 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -15,14 +15,14 @@ weight: 50 {{% /capture %}} {{% capture prerequisites %}} - 您需要拥有一个 Kubernetes 集群。按照[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)来引导一个。 {{% /capture %}} {{% capture steps %}} - diff --git a/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml index 22726c600a..580bcdf970 100644 --- a/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml +++ b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod-2.yaml @@ -9,8 +9,8 @@ spec: resources: limits: memory: "1Gi" - cpu: "800m" + cpu: "800m" requests: memory: "700Mi" cpu: "400m" - + diff --git a/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml index ba27bf5ccf..c8967d93f5 100644 --- a/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml +++ b/content/zh/docs/tasks/administer-cluster/quota-mem-cpu-pod.yaml @@ -9,8 +9,8 @@ spec: resources: limits: memory: "800Mi" - cpu: "800m" + cpu: "800m" requests: memory: "600Mi" cpu: "400m" - + diff --git a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 746c123a3d..eb570ee905 100644 --- a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -44,7 +44,7 @@ Kubernetes 将发送一个 preStop 事件。 In this exercise, you create a Pod that has one Container. The Container has handlers for the postStart and preStop events. --> -在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。 +在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。 diff --git a/content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml b/content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml index 9757018f19..895e909c19 100644 --- a/content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml +++ b/content/zh/docs/tasks/configure-pod-container/rq-compute-resources.yaml @@ -6,6 +6,6 @@ spec: hard: pods: "4" requests.cpu: "1" - requests.memory: 1Gi + requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi diff --git a/content/zh/docs/tasks/configure-pod-container/security-context-2.yaml b/content/zh/docs/tasks/configure-pod-container/security-context-2.yaml index 5a515c99e4..a0c61d37a7 100644 --- a/content/zh/docs/tasks/configure-pod-container/security-context-2.yaml +++ b/content/zh/docs/tasks/configure-pod-container/security-context-2.yaml @@ -1,7 +1,7 @@ apiVersion: v1 kind: Pod metadata: - name: security-context-demo-2 + name: security-context-demo-2 spec: securityContext: runAsUser: 1000 diff --git a/content/zh/docs/tasks/configure-pod-container/security-context.yaml b/content/zh/docs/tasks/configure-pod-container/security-context.yaml index 0795dbfe06..2175979f1e 100644 --- a/content/zh/docs/tasks/configure-pod-container/security-context.yaml +++ b/content/zh/docs/tasks/configure-pod-container/security-context.yaml @@ -1,7 +1,7 @@ apiVersion: v1 kind: Pod metadata: - name: security-context-demo + name: security-context-demo spec: securityContext: runAsUser: 1000 diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md index f833d148b4..b64176704a 100644 --- a/content/zh/docs/tasks/debug-application-cluster/audit.md +++ b/content/zh/docs/tasks/debug-application-cluster/audit.md @@ -123,7 +123,7 @@ A policy with no (0) rules is treated as illegal. Below is an example audit policy file: --> -您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 +您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。 注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。 以下是一个审计策略文件的示例： @@ -529,7 +529,7 @@ plugin which supports full-text search and analytics. diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md index 86fb3cbd95..d13718617f 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application.md @@ -29,24 +29,24 @@ $ kubectl describe pods ${POD_NAME} #### pod停留在pending状态 -如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。 -敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。 +如果一个pod卡在`Pending`状态，则表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。 +敲一下`kubectl describe ...`这个命令，输出的信息里面应该有显示为什么没被调度的原因。 常见原因如下： -* **资源不足**: +* **资源不足**: 你可能耗尽了集群上所有的CPU和内存，此时，你需要删除pods，调整资源请求，或者增加节点。 更多信息请参阅[Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) * **使用了`hostPort`**: -如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。 -多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。 +如果绑定一个pod到`hostPort`，那么能创建的pod个数就有限了。 +多数情况下，`hostPort`是非必要的，而应该采用服务来暴露pod。 如果确实需要使用`hostPort`，那么能创建的pod的数量就是节点的个数。 #### pod停留在waiting状态 -如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。 -再次敲一下`kubectl describe ...`这个命令来查看相关信息。 +如果一个pod卡在`Waiting`状态，则表示这个pod已经调试到节点上，但是没有运行起来。 +再次敲一下`kubectl describe ...`这个命令来查看相关信息。 最常见的原因是拉取镜像失败。可以通过以下三种方式来检查： * 使用的镜像名字正确吗？ @@ -81,20 +81,20 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ $ kubectl exec cassandra -- cat /var/log/cassandra/system.log ``` -如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。 -通常情况下，是不需要在Kubernetes API中再给出另外的工具的。 +如果以上方法都不起作用，找到这个pod所在的节点并用SSH登录进去做进一步的分析。 +通常情况下，是不需要在Kubernetes API中再给出另外的工具的。 因此，如果你发现需要ssh进一个主机来分析问题时，请在GitHub上提一个特性请求，描述一个你的场景并说明为什么已经提供的工具不能满足需求。 #### pod处于running态，但是没有正常工作 -如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。 -通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。 -例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。 +如果创建的pod不符合预期，那么创建pod的描述文件应该是存在某种错误的，并且这个错误在创建pod时被忽略掉。 +通常pod的定义中，章节被错误的嵌套，或者一个字段名字被写错，都可能会引起被忽略掉。 +例如，希望在pod中用命令行执行某个命令，但是将`command`写成`commnd`，pod虽然可以创建，但命令并没有执行。 -如何查出来哪里出错？ -首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数： -`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。 +如何查出来哪里出错？ +首先，删掉这个pod再重新创建一个，重创时，像下面这样带着`--validate`这个参数： +`kubectl create --validate -f mypod.yaml`，`command`写成`commnd`的拼写错误就会打印出来了。 ```shell I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd @@ -104,13 +104,13 @@ pods/mypod -如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。 +如果上面方法没有看到相关异常的信息，那么接下来就要验证从apiserver获取到的pod是否与期望的一致，比如创建Pod的yaml文件是mypod.yaml。 -运行如下命令来获取apiserver创建的pod信息并保存成一个文件： +运行如下命令来获取apiserver创建的pod信息并保存成一个文件： `kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml`。 -然后手动对这两个文件进行比较: -apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。 +然后手动对这两个文件进行比较: +apiserver获得的yaml文件中的一些行，不在创建pod的yaml文件内，这是正常的。 如果创建Pod的yaml文件内的一些行，在piserver获得的yaml文件中不存在，可以说明创建pod的yaml中的定义有问题。 @@ -122,7 +122,7 @@ RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod ### Debugging Services -服务提供了多个Pod之间的负载均衡功能。 +服务提供了多个Pod之间的负载均衡功能。 有一些常见的问题可以造成服务无法正常工作。以下说明将有助于调试服务的问题。 首先，验证服务是否有端点。对于每一个Service对像，apiserver使`endpoints`资源可用。 @@ -133,12 +133,12 @@ RC相当简单。他们要么能创建pod，要么不能。如果不能创建pod $ kubectl get endpoints ${SERVICE_NAME} ``` -确保endpoints与服务内容器个数一致。 +确保endpoints与服务内容器个数一致。 例如，如果你创建了一个nginx服务，它有3个副本，那么你就会在这个服务的endpoints中看到3个不同的IP地址。 #### 服务缺少endpoints -如果缺少endpoints，请尝试使用服务的labels列出所有的pod。 +如果缺少endpoints，请尝试使用服务的labels列出所有的pod。 假如有一个服务，有如下的label： ```yaml @@ -155,7 +155,7 @@ spec: $ kubectl get pods --selector=name=nginx,type=frontend ``` -如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。 +如果pod列表附合预期，但是endpoints仍然为空，那么可能没有暴露出正确的端口。 如果服务指定了`containerPort`，但是列表中的Pod没有列出该端口，则不会将其添加到端口列表。 验证该pod的`containerPort`与服务的`containerPort`是否匹配。 diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md index 834c0e6506..548600633e 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md @@ -2,7 +2,7 @@ title: 集群故障排查 --- -本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。 +本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。 对于应用的调试，请参阅[应用故障排查指南](/cn/docs/tasks/debug-application-cluster/debug-application)。 你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多的信息。 @@ -20,7 +20,7 @@ kubectl get nodes ## 查看logs -现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。 +现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。 (注意，对于基于systemd的系统，你可能需要使用`journalctl`) @@ -58,7 +58,7 @@ kubectl get nodes - apiserver应该不能起来 - kubelets将不能访问它，但是能够继续运行之前的Pods和提供相同的服务代理 - 在apiserver重启之前，需要手动恢复或者重创apiserver的状态 - + - Kubernetes服务组件(节点控制器，副本控制器，调度器等等)所在的VM关机或者崩溃 - 当前，这些控制器是和apiserver共存的，它们不可用的现象是与apiserver类似的 - 将来，这些控制器也会复制为多份，并且可能为非共存的 diff --git a/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md b/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md index 514167834d..f4cbbac4f5 100644 --- a/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md @@ -56,7 +56,7 @@ content_template: templates/task ``` 日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值： - + ``` command-demo tcp://10.3.240.1:443 @@ -81,7 +81,7 @@ args: ["$(MESSAGE)"] [Secrets](/docs/concepts/configuration/secret/). {{< note >}} -**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command` +**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command` 或 `args`字段使用变量的格式要求。 {{< /note >}} diff --git a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md index 017ab28e75..a583cc78d2 100644 --- a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -38,7 +38,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。 ```shell kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml - ``` + ``` {{< note >}} **注意：** 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret： @@ -105,7 +105,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。 ``` 1. 在 Pod 中运行的容器中获取一个 shell： - + ```shell kubectl exec -it secret-test-pod -- /bin/bash ``` @@ -117,7 +117,7 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。 root@secret-test-pod:/# cd /etc/secret-volume ``` 1. 在 shell 中，列出 `/etc/secret-volume` 目录的文件： - + ```shell root@secret-test-pod:/etc/secret-volume# ls ``` @@ -154,26 +154,26 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。 ``` 1. 确认 Pod 正在运行： - + ```shell kubectl get pod secret-envars-test-pod ``` 输出： - + ```shell NAME READY STATUS RESTARTS AGE secret-envars-test-pod 1/1 Running 0 4m ``` 1. 在 Pod 中运行的容器中获取一个 shell： - + ```shell kubectl exec -it secret-envars-test-pod -- /bin/bash ``` 1. 在 shell 中，显示环境变量： - + ```shell root@secret-envars-test-pod:/# printenv ``` diff --git a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index ac3f4b3913..f48d8b0536 100644 --- a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -40,7 +40,7 @@ content_template: templates/task 第二个元素指示Pod的`annotations`字段的值保存在名为`annotations`的文件中。 {{< note >}} -**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。 +**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。 {{< /note >}} 创建 Pod： diff --git a/content/zh/docs/tasks/inject-data-application/podpreset.md b/content/zh/docs/tasks/inject-data-application/podpreset.md index d7aec51d50..0f4c672b0b 100644 --- a/content/zh/docs/tasks/inject-data-application/podpreset.md +++ b/content/zh/docs/tasks/inject-data-application/podpreset.md @@ -4,7 +4,7 @@ approvers: title: 使用 PodPreset 将信息注入 Pods --- -在 pod 创建时，用户可以使用 `podpreset` 对象将 secrets、卷挂载和环境变量等信息注入其中。 +在 pod 创建时，用户可以使用 `podpreset` 对象将 secrets、卷挂载和环境变量等信息注入其中。 本文展示了一些 `PodPreset` 资源使用的示例。 用户可以从[理解 Pod Presets](/docs/concepts/workloads/pods/podpreset/) 中了解 PodPresets 的整体情况。 diff --git a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md index 1efa9b629f..f4915b8d8a 100644 --- a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -209,9 +209,9 @@ A cron job config also needs a [`.spec` section](https://git.k8s.io/community/co CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). -{{< note >}} +{{< note >}} 对 CronJob 的所有改动，特别是它的 `.spec`，只会影响将来的运行实例。 {{< /note >}} @@ -291,7 +291,7 @@ That means 120 schedules were missed, so the cron job is no longer scheduled. If field is set (not null), the CronJob controller counts how many missed jobs occurred from the value of `.spec.startingDeadlineSeconds` until now. For example, if it is set to `200`, it counts how many missed schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the -last 200 seconds, the cron job is no longer scheduled. +last 200 seconds, the cron job is no longer scheduled. --> CronJob 控制器会统计错过了多少次调度。如果错过了100次以上的调度，CronJob 就不再调度了。当没有设置 `.spec.startingDeadlineSeconds` 时，CronJob 控制器统计从`status.lastScheduleTime`到当前的调度错过次数。 diff --git a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md index 4d4d3432dc..a88be742fa 100755 --- a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -85,7 +85,7 @@ See the [Redis Example](https://github.com/kubernetes/examples/tree/master/guest of deploying Redis scalably and redundantly. --> 对于这个例子，为了简单起见，我们将启动一个单实例的 Redis。 -了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook) +了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook) 通过 kubectl 删除 StatefulSet 会将其缩容为0，因此删除属于它的所有pods。 diff --git a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md index b4956d0d8a..d015daa588 100644 --- a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md @@ -141,7 +141,7 @@ my-nginx-o0ef1 1/1 Running 0 my-nginx-q6all 1/1 Running 0 8m 2d1d7a8f682934a254002b56404b813e ``` -使用`kubectl rolling-update`可以实时看到更新的进度： +使用`kubectl rolling-update`可以实时看到更新的进度： ``` Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods) diff --git a/content/zh/docs/tasks/tls/certificate-rotation.md b/content/zh/docs/tasks/tls/certificate-rotation.md index 052e887a21..15da604e8b 100644 --- a/content/zh/docs/tasks/tls/certificate-rotation.md +++ b/content/zh/docs/tasks/tls/certificate-rotation.md @@ -22,12 +22,12 @@ content_template: templates/task ## 概述 -Kubelet 使用证书进行 Kubernetes API 的认证。 +Kubelet 使用证书进行 Kubernetes API 的认证。 默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。 Kubernetes 1.8 版本中包含 beta 特性 [kubelet 证书轮换](/docs/tasks/administer-cluster/certificate-rotation/)， 在当前证书即将过期时， -将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与 +将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与 Kubernetes API 间的连接认证。 ## 启用客户端证书轮换 @@ -57,7 +57,7 @@ Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘， 当签署的证书即将到期时，kubelet 会使用 Kubernetes API，发起新的证书签名请求。 同样地，控制器管理器会自动批准证书请求，并将签署的证书附加到证书签名请求中。 Kubelet -会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API +会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API 的连接，使用新的证书重新连接到 Kubernetes API。 {{% /capture %}} diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html index c9e45a5dab..8db7ea671a 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -3,11 +3,11 @@ title: 运行应用程序的多个实例 weight: 10 --- - diff --git a/content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md index 2e6c59fe2d..f86d24a078 100644 --- a/content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md +++ b/content/zh/docs/tutorials/object-management-kubectl/imperative-object-management-command.md @@ -134,4 +134,4 @@ kubectl create --edit -f /tmp/srv.yaml - [Kubernetes 对象模式参考](/docs/resources-reference/v1.6/) {{% /capture %}} - + diff --git a/content/zh/docs/tutorials/object-management-kubectl/object-management.md b/content/zh/docs/tutorials/object-management-kubectl/object-management.md index 85d95adfc4..805fdea87c 100644 --- a/content/zh/docs/tutorials/object-management-kubectl/object-management.md +++ b/content/zh/docs/tutorials/object-management-kubectl/object-management.md @@ -150,4 +150,4 @@ kubectl apply -R -f configs/ {{< /comment >}} {{% /capture %}} - + diff --git a/content/zh/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md index 77da6af9d0..b7cf5fb0b9 100644 --- a/content/zh/docs/tutorials/services/source-ip.md +++ b/content/zh/docs/tutorials/services/source-ip.md @@ -164,7 +164,7 @@ client_address=10.240.0.3 为了防止这种情况发生，Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`，请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints，发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下，你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。 -设置 `service.spec.externalTrafficPolicy` 字段如下： +设置 `service.spec.externalTrafficPolicy` 字段如下： ```console $ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' 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 1ae7c53847..cbf26613ea 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -67,7 +67,7 @@ kubectl get pods -w -l app=nginx 在另一个终端中，使用 [`kubectl create`](/docs/user-guide/kubectl/{{< param "version" >}}/#create) 来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml service "nginx" created statefulset "web" created ``` @@ -149,7 +149,7 @@ web-1 使用 [`kubectl run`](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 运行一个提供 `nslookup` 命令的容器，该命令来自于 `dnsutils` 包。通过对 Pod 的主机名执行 `nslookup`，你可以检查他们在集群内部的 DNS 地址。 ```shell -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -206,7 +206,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -433,7 +433,7 @@ Kubernetes 1.7 版本的 StatefulSet 控制器支持自动更新。更新策略 `OnDelete` 更新策略实现了传统（1.7之前）行为，它也是默认的更新策略。当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时， StatefulSet 控制器将不会自动的更新Pod。 -Patch `web` StatefulSet 的容器镜像。 +Patch `web` StatefulSet 的容器镜像。 ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' @@ -479,7 +479,7 @@ web-2 k8s.gcr.io/nginx-slim:0.8 ``` `web-0` 已经更新了它的镜像，但是 `web-1` 和 `web-2` 仍保留了原始镜像。 @@ -850,7 +850,7 @@ kubectl get pods -w -l app=nginx 在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 `nginx` Service （你不应该这样做），你将会看到一个错误，提示 Service 已经存在。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml statefulset "web" created Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists ``` @@ -943,7 +943,7 @@ service "nginx" deleted 再一次重新创建 StatefulSet 和 Headless Service。 ```shell -kubectl create -f web.yaml +kubectl create -f web.yaml service "nginx" created statefulset "web" created ``` @@ -1008,7 +1008,7 @@ kubectl get po -lapp=nginx -w 在另一个终端窗口创建清单中的 StatefulSet 和 Service。 ```shell -kubectl create -f webp.yaml +kubectl create -f webp.yaml service "nginx" created statefulset "web" created ``` @@ -1052,7 +1052,7 @@ web-3 1/1 Running 0 26s ```