From 3ae1132344bc107a157dbd82699d4ae4ed02c8b1 Mon Sep 17 00:00:00 2001 From: bin liu Date: Wed, 22 Nov 2017 16:40:42 +0800 Subject: [PATCH] fix some typo and syntax error --- concepts/init-containers.md | 4 ++-- concepts/objects.md | 4 ++-- concepts/pod-overview.md | 6 +++--- concepts/pod.md | 12 ++++++------ usecases/configuring-request-routing.md | 2 +- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/concepts/init-containers.md b/concepts/init-containers.md index bc611905d..b5df37754 100644 --- a/concepts/init-containers.md +++ b/concepts/init-containers.md @@ -237,11 +237,11 @@ Pod 能够重启，会导致 Init 容器重新执行，主要有如下几个原 - 用户更新 PodSpec 导致 Init 容器镜像发生改变。应用容器镜像的变更只会重启应用容器。 - Pod 基础设施容器被重启。这不多见，但某些具有 root 权限可访问 Node 的人可能会这样做。 -- 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止，强制重启，由于垃圾收集导致 Init 容器完成的记录丢失。 +- 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止，强制重启，由于垃圾收集导致 Init 容器完整的记录丢失。 ## 支持与兼容性 -Apiserver 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。 之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。 `spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 apiserver 能够安全的回退到 1.5.x 版本，而不会使存在的已创建 Pod 失去 Init 容器的功能。 +Apiserver 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。 之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。 `spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 apiserver 能够安全地回退到 1.5.x 版本，而不会使存在的已创建 Pod 失去 Init 容器的功能。 原文地址：https://k8smeetup.github.io/docs/concepts/workloads/pods/init-containers/ diff --git a/concepts/objects.md b/concepts/objects.md index cab9a8154..1f6c996b1 100644 --- a/concepts/objects.md +++ b/concepts/objects.md @@ -57,7 +57,7 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete ### 描述 Kubernetes 对象 -当创建 KUbernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如，名称）。当使用 KUbernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。**更常用的是，需要在 .yaml 文件中为 kubectl 提供这些信息**。 `kubectl` 在执行 API 请求时，将这些信息转换成 JSON 格式。 +当创建 Kubernetes 对象时，必须提供对象的 spec，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如，名称）。当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。**更常用的是，需要在 .yaml 文件中为 kubectl 提供这些信息**。 `kubectl` 在执行 API 请求时，将这些信息转换成 JSON 格式。 这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象 spec： @@ -94,7 +94,7 @@ deployment "nginx-deployment" created ### 必需字段 -在想要创建的 KUbernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段： +在想要创建的 Kubernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段： - `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本 - `kind` - 想要创建的对象的类型 diff --git a/concepts/pod-overview.md b/concepts/pod-overview.md index 046877b30..c2f2dbf90 100644 --- a/concepts/pod-overview.md +++ b/concepts/pod-overview.md @@ -15,18 +15,18 @@ Pods are employed a number of ways in a Kubernetes cluster, including: - **一个Pod中运行一个容器**。“每个Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。 - **在一个Pod中同时运行多个容器**。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位——一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。 -[Kubernetes Blog](http://blog.kubernetes.io) 有关于Pod用例的详细信息：查看： +[Kubernetes Blog](http://blog.kubernetes.io) 有关于Pod用例的详细信息，查看： - [The Distributed System Toolkit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) - [Container Design Patterns](http://blog.kubernetes.io/2016/06/container-design-patterns.html) -每个Pod都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个Pod，每个Pod都是一个应用实例。在Kubernetes中，这通常被叫称为是replication。 +每个Pod都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个Pod，每个Pod都是一个应用实例。在Kubernetes中，这通常被称为replication。 ### Pod中如何管理多个容器 Pod中可以同时运行多个进程（作为容器运行）协同工作。同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。 -注意在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个”sidecar“容器来从远端获取资源更新这些文件，如下图所示： +注意在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件，如下图所示： ![pod diagram](../images/pod-overview.png) diff --git a/concepts/pod.md b/concepts/pod.md index 24616e762..df8b0b48c 100644 --- a/concepts/pod.md +++ b/concepts/pod.md @@ -8,17 +8,17 @@ V1 core版本的Pod的配置模板见[Pod template](../manifests/template/pod-v1 Pod就像是豌豆荚一样，它由一个或者多个容器组成（例如Docker容器），它们共享容器存储、网络和容器运行配置项。Pod中的容器总是被同时调度，有共同的运行环境。你可以把单个Pod想象成是运行独立应用的“逻辑主机”——其中运行着一个或者多个紧密耦合的应用容器——在有容器之前，这些应用都是运行在几个相同的物理机或者虚拟机上。 -尽管kubernetes支持多种容器运行时，但是docker依然是最常用的运行时环境，我们可以使用docker的术语和规则来定义Pod。 +尽管kubernetes支持多种容器运行时，但是Docker依然是最常用的运行时环境，我们可以使用Docker的术语和规则来定义Pod。 -Pod中共享的环境包括Linux的namespace，cgroup和其他可能的隔绝环境，这一点跟docker容器一致。在Pod的环境中，每个容器中可能还有更小的子隔离环境。 +Pod中共享的环境包括Linux的namespace，cgroup和其他可能的隔绝环境，这一点跟Docker容器一致。在Pod的环境中，每个容器中可能还有更小的子隔离环境。 Pod中的容器共享IP地址和端口号，它们之间可以通过`localhost`互相发现。它们之间可以通过进程间通信，例如[SystemV](https://en.wikipedia.org/wiki/UNIX_System_V)信号或者POSIX共享内存。不同Pod之间的容器具有不同的IP地址，不能直接通过IPC通信。 Pod中的容器也有访问共享volume的权限，这些volume会被定义成pod的一部分并挂载到应用容器的文件系统中。 -根据docker的结构，Pod中的容器共享namespace和volume，不支持共享PID的namespace。 +根据Docker的结构，Pod中的容器共享namespace和volume，不支持共享PID的namespace。 -就像每个应用容器，pod被认为是临时（非持久的）实体。在Pod的生命周期中讨论过，pod被创建后，被分配一个唯一的UI（UID），调度到节点上，并一致维持期望的状态直到被终结（根据重启策略）或者被删除。如果node死掉了，分配到了这个node上的pod，在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod（如UID定义的）不会被“重新调度”到新的节点上，而是被一个同样的pod取代，如果期望的话甚至可以是相同的名字，但是会有一个新的UID（查看replication controller获取详情）。（未来，一个更高级别的API将支持pod迁移）。 +就像每个应用容器，pod被认为是临时（非持久的）实体。在Pod的生命周期中讨论过，pod被创建后，被分配一个唯一的ID（UID），调度到节点上，并一致维持期望的状态直到被终结（根据重启策略）或者被删除。如果node死掉了，分配到了这个node上的pod，在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod（如UID定义的）不会被“重新调度”到新的节点上，而是被一个同样的pod取代，如果期望的话甚至可以是相同的名字，但是会有一个新的UID（查看replication controller获取详情）。（未来，一个更高级别的API将支持pod迁移）。 Volume跟pod有相同的生命周期（当其UID存在的时候）。当Pod因为某种原因被删除或者被新创建的相同的Pod取代，它相关的东西（例如volume）也会被销毁和再创建一个新的volume。 @@ -114,9 +114,9 @@ Pod的强制删除是通过在集群和etcd中将其定义为删除状态。当 ## Pod中容器的特权模式 -从kubernetes1.1版本开始，pod中的容器就可以开启previleged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用linux的网络操作和访问设备的能力时是很用的。同时开启的特权模式的Pod中的容器也可以访问到容器外的进程和应用。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。 +从kubernetes1.1版本开始，pod中的容器就可以开启previleged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用Linux的网络操作和访问设备的能力时是很用的。同时开启的特权模式的Pod中的容器也可以访问到容器外的进程和应用。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。 -如果master节点运行的是kuberentes1.1.或更高版本，而node节点的版本低于1.1版本，则API server将也可以接受新的特权模式的pod，但是无法启动，pod将处于pending状态。 +如果master节点运行的是kuberentes1.1或更高版本，而node节点的版本低于1.1版本，则API server将也可以接受新的特权模式的pod，但是无法启动，pod将处于pending状态。 执行 `kubectl describe pod FooPodName`，可以看到为什么pod处于pending状态。输出的event列表中将显示： `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` diff --git a/usecases/configuring-request-routing.md b/usecases/configuring-request-routing.md index a946f0ac4..986f61425 100644 --- a/usecases/configuring-request-routing.md +++ b/usecases/configuring-request-routing.md @@ -70,7 +70,7 @@ 由于对代理的规则传播是异步的，因此在尝试访问应用程序之前，需要等待几秒钟才能将规则传播到所有pod。 -2. 在浏览器中打开BookInfo URL（http://$GATEWAY_URL/productpage，我们在上一节中使用的是 http://ingress.istio.io/productpage ）您应该会看到BookInfo应用程序的产品页面显示。 注意，产品页面上没有评分星，因为`reviews:v1`不访问评级服务。 +2. 在浏览器中打开BookInfo URL（http://$GATEWAY_URL/productpage ，我们在上一节中使用的是 http://ingress.istio.io/productpage ）您应该会看到BookInfo应用程序的产品页面显示。 注意，产品页面上没有评分星，因为`reviews:v1`不访问评级服务。 3. 将特定用户路由到`reviews:v2`。