Merge branch 'master' into patch-1
This commit is contained in:
iamhesir
@@ -17,10 +17,9 @@ weight: 10
|
||||
<!--
|
||||
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
|
||||
A node may be a virtual or physical machine, depending on the cluster. Each node
|
||||
is managed by the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
|
||||
and contains the services necessary to run
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}
|
||||
contains the services necessary to run
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
|
||||
Typically you have several nodes in a cluster; in a learning or resource-limited
|
||||
environment, you might have just one.
|
||||
@@ -31,9 +30,9 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
|
||||
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
|
||||
-->
|
||||
Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。
|
||||
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点由
|
||||
{{< glossary_tooltip text="控制面" term_id="control-plane" >}} 负责管理，
|
||||
并包含运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所需的服务。
|
||||
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。
|
||||
每个节点包含运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所需的服务，
|
||||
这些 Pods 由 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 负责管理。
|
||||
|
||||
通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能
|
||||
只有一个节点。
|
||||
@@ -121,7 +120,7 @@ register itself with the API server. This is the preferred pattern, used by mos
|
||||
|
||||
For self-registration, the kubelet is started with the following options:
|
||||
-->
|
||||
### 节点自注册
|
||||
### 节点自注册 {#self-registration-of-nodes}
|
||||
|
||||
当 kubelet 标志 `--register-node` 为 true（默认）时，它会尝试向 API 服务注册自己。
|
||||
这是首选模式，被绝大多数发行版选用。
|
||||
@@ -171,7 +170,7 @@ When you want to create Node objects manually, set the kubelet flag `--register-
|
||||
You can modify Node objects regardless of the setting of `--register-node`.
|
||||
For example, you can set labels on an existing Node, or mark it unschedulable.
|
||||
-->
|
||||
### 手动节点管理
|
||||
### 手动节点管理 {#manual-node-administration}
|
||||
|
||||
你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
|
||||
来创建和修改 Node 对象。
|
||||
@@ -457,8 +456,7 @@ of the node heartbeats as the cluster scales.
|
||||
#### 心跳机制 {#heartbeats}
|
||||
|
||||
Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。
|
||||
心跳有两种形式：`NodeStatus` 和 [`Lease` 对象]
|
||||
(/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。
|
||||
心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。
|
||||
每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}}
|
||||
中都有一个与之关联的 `Lease` 对象。
|
||||
`Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。
|
||||
|
||||
@@ -39,7 +39,7 @@ integrate with Kubernetes. The following sections describe how to handle and sto
|
||||
-->
|
||||
集群级日志架构需要一个独立的后端用来存储、分析和查询日志。
|
||||
Kubernetes 并不为日志数据提供原生的存储解决方案。
|
||||
相反，有很多现成的日志方案可以集成到 Kubernetes 中.
|
||||
相反，有很多现成的日志方案可以集成到 Kubernetes 中。
|
||||
下面各节描述如何在节点上处理和存储日志。
|
||||
|
||||
<!--
|
||||
@@ -458,7 +458,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c
|
||||
<!--
|
||||
For information about configuring fluentd, see the [fluentd documentation](https://docs.fluentd.org/).
|
||||
-->
|
||||
要进一步了解如何配置 fluentd，请参考 [fluentd 官方文档](https://docs.fluentd.org/).
|
||||
要进一步了解如何配置 fluentd，请参考 [fluentd 官方文档](https://docs.fluentd.org/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
||||
@@ -24,8 +24,8 @@ problems to address:
|
||||
1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}}
|
||||
和 `localhost` 通信解决了。
|
||||
2. Pod 间通信：这个是本文档的重点要讲述的。
|
||||
3. Pod 和服务间通信：这个已经在[服务](/zh/docs/concepts/services-networking/service/) 里讲述过了。
|
||||
4. 外部和服务间通信：这也已经在[服务](/zh/docs/concepts/services-networking/service/) 讲述过了。
|
||||
3. Pod 和服务间通信：这个已经在[服务](/zh/docs/concepts/services-networking/service/)里讲述过了。
|
||||
4. 外部和服务间通信：这也已经在[服务](/zh/docs/concepts/services-networking/service/)讲述过了。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -82,9 +82,9 @@ Linux):
|
||||
Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）：
|
||||
|
||||
* 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
|
||||
* 节点上的代理（比如：系统守护进程、kubelet） 可以和节点上的所有Pod通信
|
||||
* 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有Pod通信
|
||||
|
||||
备注：仅针对那些支持 `Pods` 在主机网络中运行的平台(比如：Linux) ：
|
||||
备注：仅针对那些支持 `Pods` 在主机网络中运行的平台（比如：Linux）：
|
||||
|
||||
* 那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信
|
||||
|
||||
@@ -107,7 +107,7 @@ usage, but this is no different from processes in a VM. This is called the
|
||||
Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。
|
||||
这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。
|
||||
这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同，
|
||||
这也被称为“一个 Pod 一个 IP” 模型。
|
||||
这也被称为“一个 Pod 一个 IP”模型。
|
||||
|
||||
<!--
|
||||
How this is implemented is a detail of the particular container runtime in use.
|
||||
@@ -119,7 +119,7 @@ blind to the existence or non-existence of host ports.
|
||||
-->
|
||||
如何实现这一点是正在使用的容器运行时的特定信息。
|
||||
|
||||
也可以在 `node` 本身通过端口去请求你的 `Pod` （称之为主机端口），
|
||||
也可以在 `node` 本身通过端口去请求你的 `Pod`（称之为主机端口），
|
||||
但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。
|
||||
`Pod` 自己并不知道这些主机端口是否存在。
|
||||
|
||||
@@ -196,7 +196,7 @@ AOS 具有一组丰富的 REST API 端点，这些端点使 Kubernetes 能够根
|
||||
从而为私有云和公共云提供端到端管理系统。
|
||||
|
||||
AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备，
|
||||
以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux 。
|
||||
以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux。
|
||||
|
||||
想要更详细地了解 AOS 系统是如何工作的可以点击这里：https://www.apstra.com/products/how-it-works/
|
||||
|
||||
@@ -218,10 +218,10 @@ AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可
|
||||
|
||||
使用该 CNI 插件，可使 Kubernetes Pod 拥有与在 VPC 网络上相同的 IP 地址。
|
||||
CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod 。
|
||||
CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达2000个节点的大型集群。
|
||||
CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达 2000 个节点的大型集群。
|
||||
|
||||
此外，CNI 可以与
|
||||
[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)一起运行。
|
||||
[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) 一起运行。
|
||||
AWS VPC CNI 项目是开源的，请查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。
|
||||
|
||||
<!--
|
||||
@@ -482,7 +482,7 @@ Docker 会以这样的参数启动：
|
||||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
这个网桥是由 Kubelet（由 --network-plugin=kubenet 参数控制）根据节点的 `.spec.podCIDR` 参数创建的。
|
||||
这个网桥是由 Kubelet（由 `--network-plugin=kubenet` 参数控制）根据节点的 `.spec.podCIDR` 参数创建的。
|
||||
|
||||
Docker 将会从 `cbr-cidr` 块分配 IP。
|
||||
容器之间可以通过 `cbr0` 网桥相互访问，也可以访问节点。
|
||||
|
||||
@@ -266,7 +266,7 @@ In `$HOME/.kube/config`, relative paths are stored relatively, and absolute path
|
||||
are stored absolutely.
|
||||
-->
|
||||
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。
|
||||
命令行上的文件引用是相当对于当前工作目录的。
|
||||
命令行上的文件引用是相对于当前工作目录的。
|
||||
在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -92,10 +92,10 @@ These controllers include:
|
||||
-->
|
||||
这些控制器包括:
|
||||
|
||||
* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
|
||||
* 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
|
||||
* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
|
||||
* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.
|
||||
* 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
|
||||
* 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod
|
||||
* 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
|
||||
* 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
|
||||
|
||||
<!--
|
||||
### cloud-controller-manager
|
||||
|
||||
@@ -253,7 +253,7 @@ paired with system groups to grant access to all pods run in the namespace:
|
||||
可以考虑将这种授权模式和系统组结合，对名字空间中的所有 Pod 授予访问权限。
|
||||
|
||||
```yaml
|
||||
# 授权该某名字空间中所有服务账号
|
||||
# 授权某名字空间中所有服务账号
|
||||
- kind: Group
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: system:serviceaccounts
|
||||
|
||||
@@ -148,13 +148,13 @@ one of these at random.
|
||||
最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。
|
||||
如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
There are two supported ways to configure the filtering and scoring behavior
|
||||
of the scheduler:
|
||||
-->
|
||||
支持以下两种方式配置调度器的过滤和打分行为：
|
||||
|
||||
<!--
|
||||
<!--
|
||||
1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to
|
||||
configure _Predicates_ for filtering and _Priorities_ for scoring.
|
||||
1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to
|
||||
@@ -162,14 +162,14 @@ of the scheduler:
|
||||
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
|
||||
can also configure the kube-scheduler to run different profiles.
|
||||
-->
|
||||
1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_
|
||||
1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_
|
||||
和打分的 _优先级(Priorities)_ 。
|
||||
2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，
|
||||
包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。
|
||||
你也可以配置 kube-scheduler 运行不同的配置文件。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
<!--
|
||||
<!--
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
@@ -183,4 +183,3 @@ of the scheduler:
|
||||
* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
|
||||
* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
|
||||
* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 40
|
||||
<!--
|
||||
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
|
||||
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
|
||||
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
|
||||
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
|
||||
hard requirement). Taints are the opposite -they allow a node to repel a set of pods.
|
||||
-->
|
||||
节点亲和性（详见[这里](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)）
|
||||
@@ -140,7 +140,7 @@ This is a "preference" or "soft" version of `NoSchedule` - the system will *try*
|
||||
pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
|
||||
`NoExecute`, described later.
|
||||
-->
|
||||
上述例子使用到的 `effect` 的一个值 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。
|
||||
上述例子中 `effect` 使用的值为 `NoSchedule`，您也可以使用另外一个值 `PreferNoSchedule`。
|
||||
这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上，
|
||||
但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。
|
||||
|
||||
@@ -438,7 +438,7 @@ by the user already has a toleration for `node.kubernetes.io/unreachable`.
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度
|
||||
并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为
|
||||
并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为
|
||||
`node.kubernetes.io/not-ready` 的容忍度。
|
||||
|
||||
同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度
|
||||
@@ -517,5 +517,3 @@ arbitrary tolerations to DaemonSets.
|
||||
-->
|
||||
* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
|
||||
* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
|
||||
|
||||
|
||||
|
||||
@@ -349,7 +349,7 @@ caused by previous runs.
|
||||
`.spec.template.spec.restartPolicy = "Never"`。
|
||||
当 Pod 失败时，Job 控制器会启动一个新的 Pod。
|
||||
这意味着，你的应用需要处理在一个新 Pod 中被重启的情况。
|
||||
尤其是应用需要处理之前运行所触碰或产生的临时文件、锁、不完整的输出等问题。
|
||||
尤其是应用需要处理之前运行所产生的临时文件、锁、不完整的输出等问题。
|
||||
|
||||
<!--
|
||||
Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
title: Kubernetes 问题追踪
|
||||
weight: 10
|
||||
aliases: [cve/,cves/]
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Kubernetes 安全和信息披露
|
||||
aliases: [security/]
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -3,16 +3,16 @@ title: 调度器配置
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
<!--
|
||||
title: Scheduler Configuration
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
You can customize the behavior of the `kube-scheduler` by writing a configuration
|
||||
file and passing its path as a command line argument.
|
||||
file and passing its path as a command line argument.
|
||||
-->
|
||||
你可以通过编写配置文件，并将其路径传给 `kube-scheduler` 的命令行参数，定制 `kube-scheduler` 的行为。
|
||||
|
||||
@@ -82,14 +82,14 @@ extension points:
|
||||
-->
|
||||
1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。
|
||||
一次只能启用一个队列排序插件。
|
||||
<!--
|
||||
<!--
|
||||
2. `PreFilter`: These plugins are used to pre-process or check information
|
||||
about a Pod or the cluster before filtering. They can mark a pod as
|
||||
unschedulable.
|
||||
-->
|
||||
2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
|
||||
它们可以将 Pod 标记为不可调度。
|
||||
<!--
|
||||
<!--
|
||||
3. `Filter`: These plugins are the equivalent of Predicates in a scheduling
|
||||
Policy and are used to filter out nodes that can not run the Pod. Filters
|
||||
are called in the configured order. A pod is marked as unschedulable if no
|
||||
@@ -98,7 +98,7 @@ extension points:
|
||||
3. `Filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
|
||||
过滤器的调用顺序是可配置的。
|
||||
如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。
|
||||
<!--
|
||||
<!--
|
||||
4. `PreScore`: This is an informational extension point that can be used
|
||||
for doing pre-scoring work.
|
||||
-->
|
||||
@@ -127,13 +127,13 @@ extension points:
|
||||
least one bind plugin is required.
|
||||
-->
|
||||
9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
|
||||
<!--
|
||||
<!--
|
||||
10. `PostBind`: This is an informational extension point that is called after
|
||||
a Pod has been bound.
|
||||
-->
|
||||
10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
For each extension point, you could disable specific [default plugins](#scheduling-plugins)
|
||||
or enable your own. For example:
|
||||
-->
|
||||
@@ -154,18 +154,18 @@ profiles:
|
||||
weight: 1
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
You can use `*` as name in the disabled array to disable all default plugins
|
||||
for that extension point. This can also be used to rearrange plugins order, if
|
||||
desired.
|
||||
-->
|
||||
你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。
|
||||
如果需要，这个字段也可以用来对插件重新顺序。
|
||||
|
||||
|
||||
<!-- ### Scheduling plugins -->
|
||||
### 调度插件 {#scheduling-plugin}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
1. `UnReserve`: This is an informational extension point that is called if
|
||||
a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
|
||||
-->
|
||||
@@ -190,7 +190,7 @@ extension points:
|
||||
- `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、
|
||||
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。
|
||||
|
||||
|
||||
实现的扩展点：`PreScore`，`Score`。
|
||||
<!--
|
||||
- `ImageLocality`: Favors nodes that already have the container images that the
|
||||
@@ -198,7 +198,7 @@ extension points:
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `TaintToleration`: Implements
|
||||
@@ -206,21 +206,21 @@ extension points:
|
||||
Implements extension points: `Filter`, `Prescore`, `Score`.
|
||||
-->
|
||||
- `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`，`Prescore`，`Score`。
|
||||
<!--
|
||||
- `NodeName`: Checks if a Pod spec node name matches the current node.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `NodePorts`: Checks if a node has free ports for the requested Pod ports.
|
||||
Extension points: `PreFilter`, `Filter`.
|
||||
-->
|
||||
- `NodePorts`：检查 Pod 请求的端口在节点上是否可用。
|
||||
|
||||
|
||||
实现的扩展点：`PreFilter`，`Filter`。
|
||||
<!--
|
||||
- `NodePreferAvoidPods`: Scores nodes according to the node
|
||||
@@ -228,9 +228,9 @@ extension points:
|
||||
`scheduler.alpha.kubernetes.io/preferAvoidPods`.
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}}
|
||||
- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}}
|
||||
`scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `NodeAffinity`: Implements
|
||||
@@ -240,7 +240,7 @@ extension points:
|
||||
-->
|
||||
- `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
|
||||
和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`，`Score`.
|
||||
<!--
|
||||
- `PodTopologySpread`: Implements
|
||||
@@ -248,7 +248,7 @@ extension points:
|
||||
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
|
||||
-->
|
||||
- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
|
||||
|
||||
|
||||
实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
|
||||
<!--
|
||||
- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
|
||||
@@ -256,7 +256,7 @@ extension points:
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is
|
||||
@@ -264,7 +264,7 @@ extension points:
|
||||
Extension points: `PreFilter`, `Filter`.
|
||||
-->
|
||||
- `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。
|
||||
|
||||
|
||||
实现的扩展点：`PreFilter`，`Filter`。
|
||||
<!--
|
||||
- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more
|
||||
@@ -272,7 +272,7 @@ extension points:
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of
|
||||
@@ -280,7 +280,7 @@ extension points:
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodeResourcesLeastAllocated`：选择资源分配较少的节点。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `VolumeBinding`: Checks if the node has or if it can bind the requested
|
||||
@@ -288,15 +288,15 @@ extension points:
|
||||
Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`.
|
||||
-->
|
||||
- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。
|
||||
|
||||
|
||||
实现的扩展点: `PreFilter`，`Filter`，`Reserve`，`PreBind`。
|
||||
<!--
|
||||
<!--
|
||||
- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy
|
||||
restrictions that are specific to the volume provider.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they
|
||||
@@ -304,29 +304,29 @@ extension points:
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `VolumeZone`：检查请求的卷是否在任何区域都满足。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
<!--
|
||||
- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the
|
||||
node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for
|
||||
@@ -334,7 +334,7 @@ extension points:
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `InterPodAffinity`: Implements
|
||||
@@ -342,28 +342,28 @@ extension points:
|
||||
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
|
||||
-->
|
||||
- `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。
|
||||
|
||||
|
||||
实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
|
||||
<!--
|
||||
- `PrioritySort`: Provides the default priority based sorting.
|
||||
Extension points: `QueueSort`.
|
||||
-->
|
||||
- `PrioritySort`：提供默认的基于优先级的排序。
|
||||
|
||||
|
||||
实现的扩展点：`QueueSort`。
|
||||
<!--
|
||||
- `DefaultBinder`: Provides the default binding mechanism.
|
||||
Extension points: `Bind`.
|
||||
-->
|
||||
- `DefaultBinder`：提供默认的绑定机制。
|
||||
|
||||
|
||||
实现的扩展点：`Bind`。
|
||||
<!--
|
||||
- `DefaultPreemption`: Provides the default preemption mechanism.
|
||||
Extension points: `PostFilter`.
|
||||
-->
|
||||
- `DefaultPreemption`：提供默认的抢占机制。
|
||||
|
||||
|
||||
实现的扩展点：`PostFilter`。
|
||||
|
||||
<!--
|
||||
@@ -378,7 +378,7 @@ that are not enabled by default:
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodeResourcesMostAllocated`：选择已分配资源多的节点。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `RequestedToCapacityRatio`: Favor nodes according to a configured function of
|
||||
@@ -386,14 +386,14 @@ that are not enabled by default:
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。
|
||||
|
||||
|
||||
实现的扩展点：`Score`。
|
||||
<!--
|
||||
- `NodeResourceLimits`: Favors nodes that satisfy the Pod resource limits.
|
||||
Extension points: `PreScore`, `Score`.
|
||||
-->
|
||||
- `NodeResourceLimits`：选择满足 Pod 资源限制的节点。
|
||||
|
||||
|
||||
实现的扩展点：`PreScore`，`Score`。
|
||||
<!--
|
||||
- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
|
||||
@@ -401,16 +401,16 @@ that are not enabled by default:
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`。
|
||||
<!--
|
||||
- `NodeLabel`: Filters and / or scores a node according to configured
|
||||
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
|
||||
Extension points: `Filter`, `Score`.
|
||||
-->
|
||||
- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}}
|
||||
- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}}
|
||||
过滤节点和/或给节点打分。
|
||||
|
||||
|
||||
实现的扩展点：`Filter`，`Score`。
|
||||
<!--
|
||||
- `ServiceAffinity`: Checks that Pods that belong to a
|
||||
@@ -422,7 +422,7 @@ that are not enabled by default:
|
||||
- `ServiceAffinity`：检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod
|
||||
与配置的标签所定义的节点集是否适配。
|
||||
这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。
|
||||
|
||||
|
||||
实现的扩展点：`PreFilter`，`Filter`，`Score`。
|
||||
|
||||
<!-- ### Multiple profiles -->
|
||||
@@ -462,14 +462,14 @@ profiles:
|
||||
Pods that want to be scheduled according to a specific profile can include
|
||||
the corresponding scheduler name in its `.spec.schedulerName`.
|
||||
-->
|
||||
希望根据特定配置文件调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。
|
||||
对于那些希望根据特定配置文件来进行调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。
|
||||
|
||||
<!--
|
||||
By default, one profile with the scheduler name `default-scheduler` is created.
|
||||
This profile includes the default plugins described above. When declaring more
|
||||
than one profile, a unique scheduler name for each of them is required.
|
||||
-->
|
||||
默认情况下，将创建一个名为 `default-scheduler` 的配置文件。
|
||||
默认情况下，将创建一个调度器名为 `default-scheduler` 的配置文件。
|
||||
这个配置文件包括上面描述的所有默认插件。
|
||||
声明多个配置文件时，每个配置文件中调度器名称必须唯一。
|
||||
|
||||
@@ -478,8 +478,8 @@ If a Pod doesn't specify a scheduler name, kube-apiserver will set it to
|
||||
`default-scheduler`. Therefore, a profile with this scheduler name should exist
|
||||
to get those pods scheduled.
|
||||
-->
|
||||
如果 Pod 未指定调度器名称，kube-apiserver 将会把它设置为 `default-scheduler`。
|
||||
因此，应该存在一个名为 `default-scheduler` 的配置文件来调度这些 Pod。
|
||||
如果 Pod 未指定调度器名称，kube-apiserver 将会把调度器名设置为 `default-scheduler`。
|
||||
因此，应该存在一个调度器名为 `default-scheduler` 的配置文件来调度这些 Pod。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
@@ -488,7 +488,7 @@ Events for leader election use the scheduler name of the first profile in the
|
||||
list.
|
||||
-->
|
||||
Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController。
|
||||
领导者选择事件使用列表中第一个配置文件的调度器名称。
|
||||
领导者选举事件使用列表中第一个配置文件的调度器名称。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
@@ -498,7 +498,7 @@ the same configuration parameters (if applicable). This is because the scheduler
|
||||
only has one pending pods queue.
|
||||
-->
|
||||
所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
|
||||
这是因为调度器只有一个的队列保存悬决的 Pod。
|
||||
这是因为调度器只有一个保存 pending 状态 Pod 的队列。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
@@ -509,4 +509,4 @@ only has one pending pods queue.
|
||||
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
-->
|
||||
* 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
|
||||
@@ -111,6 +111,7 @@ their authors, not the Kubernetes team.
|
||||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
|
||||
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
|
||||
@@ -145,6 +146,7 @@ their authors, not the Kubernetes team.
|
||||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
|
||||
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
|
||||
|
||||
@@ -39,7 +39,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
|
||||
* 如果你正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
|
||||
* [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。
|
||||
* 安装 v2.7.0 或更高版本的 [Helm](https://helm.sh/)。
|
||||
* 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。
|
||||
* 遵照 [Helm 安装说明](https://helm.sh/docs/intro/install/)。
|
||||
* 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
@@ -62,13 +62,13 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成
|
||||
|
||||
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/)
|
||||
-->
|
||||
## 无状态应用程序
|
||||
|
||||
* [公开外部 IP 地址访问集群中的应用程序](/zh/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
* [示例：使用 Redis 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/)
|
||||
* [示例：使用 MongoDB 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/)
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
@@ -52,14 +52,14 @@ Kubernetes 允许你将加载到节点上的 seccomp 配置文件自动应用于
|
||||
<!--
|
||||
In order to complete all steps in this tutorial, you must install
|
||||
[kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
|
||||
[kubectl](/doc/tasks/tools/install-kubectl/). This tutorial will show examples
|
||||
[kubectl](/docs/tasks/tools/install-kubectl/). This tutorial will show examples
|
||||
with both alpha (pre-v1.19) and generally available seccomp functionality, so
|
||||
make sure that your cluster is [configured
|
||||
correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
|
||||
for the version you are using.
|
||||
-->
|
||||
为了完成本教程中的所有步骤，你必须安装 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/)
|
||||
和 [kubectl](/zh/doc/tasks/tools/install-kubectl/)。本教程将显示同时具有 alpha（v1.19 之前的版本）
|
||||
和 [kubectl](/zh/docs/tasks/tools/install-kubectl/)。本教程将显示同时具有 alpha（v1.19 之前的版本）
|
||||
和通常可用的 seccomp 功能的示例，因此请确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ Dockerfile、kubernetes.yml、Kubernetes ConfigMaps、和 Kubernetes Secrets。
|
||||
比如赋值给不同的容器中的不同环境变量。
|
||||
|
||||
<!--
|
||||
ConfigMaps are API Objects that store non-confidential key-value pairs. In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name. For more information regarding ConfigMaps, you can find the documentation [here].
|
||||
ConfigMaps are API Objects that store non-confidential key-value pairs. In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name. For more information regarding ConfigMaps, you can find the documentation [here](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
|
||||
Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they're intended for confidential/sensitive information and are stored using Base64 encoding. This makes secrets the appropriate choice for storing such things as credentials, keys, and tokens, the former of which you'll do in the Interactive Tutorial. For more information on Secrets, you can find the documentation [here](/docs/concepts/configuration/secret/).
|
||||
-->
|
||||
@@ -90,4 +90,4 @@ CDI & MicroProfile 都会被用在互动教程中，
|
||||
### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
|
||||
-->
|
||||
## 示例：使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置
|
||||
### [启动互动教程](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
|
||||
### [启动互动教程](/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
|
||||
|
||||
@@ -103,15 +103,23 @@ clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
||||
|
||||
从相同集群中的一个 pod 访问这个 `ClusterIP`：
|
||||
|
||||
```console
|
||||
```shell
|
||||
kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
```
|
||||
输出结果与以下结果类似：
|
||||
```
|
||||
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
```
|
||||
|
||||
# ip addr
|
||||
然后你可以在 Pod 内运行命令：
|
||||
|
||||
```shell
|
||||
# 在终端内使用"kubectl run"执行
|
||||
|
||||
ip addr
|
||||
```
|
||||
```
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
|
||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
@@ -124,8 +132,15 @@ If you don't see a command prompt, try pressing enter.
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
```
|
||||
|
||||
# wget -qO - 10.0.170.92
|
||||
然后使用 `wget` 去请求本地 Web 服务器
|
||||
```shell
|
||||
# 用名为 "clusterip" 的服务的 IPv4 地址替换 "10.0.170.92"
|
||||
|
||||
wget -qO - 10.0.170.92
|
||||
```
|
||||
```
|
||||
CLIENT VALUES:
|
||||
client_address=10.244.3.8
|
||||
command=GET
|
||||
@@ -178,17 +193,19 @@ client_address=10.240.0.3
|
||||
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
\ ^
|
||||
\ \
|
||||
v \
|
||||
node 1 <--- node 2
|
||||
| ^ SNAT
|
||||
| | --->
|
||||
v |
|
||||
endpoint
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client(client)-->node2[节点 2];
|
||||
node2-->client;
|
||||
node2-. SNAT .->node1[节点 1];
|
||||
node1-. SNAT .->node2;
|
||||
node1-->endpoint(端点);
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
class node1,node2,endpoint k8s;
|
||||
class client plain;
|
||||
{{</ mermaid >}}
|
||||
|
||||
|
||||
为了防止这种情况发生，Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`，请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints，发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下，你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。
|
||||
@@ -229,17 +246,18 @@ client_address=104.132.1.79
|
||||
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
^ / \
|
||||
/ / \
|
||||
/ v X
|
||||
node 1 node 2
|
||||
^ |
|
||||
| |
|
||||
| v
|
||||
endpoint
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph TD;
|
||||
client --> node1[节点 1];
|
||||
client(client) --x node2[节点 2];
|
||||
node1 --> endpoint(端点);
|
||||
endpoint --> node1;
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
class node1,node2,endpoint k8s;
|
||||
class client plain;
|
||||
{{</ mermaid >}}
|
||||
|
||||
|
||||
|
||||
@@ -285,17 +303,7 @@ client_address=10.240.0.5
|
||||
|
||||
用图表示：
|
||||
|
||||
```
|
||||
client
|
||||
|
|
||||
lb VIP
|
||||
/ ^
|
||||
v /
|
||||
health check ---> node 1 node 2 <--- health check
|
||||
200 <--- ^ | ---> 500
|
||||
| V
|
||||
endpoint
|
||||
```
|
||||
|
||||
|
||||
|
||||
你可以设置 annotation 来进行测试：
|
||||
@@ -367,7 +375,7 @@ __跨平台支持__
|
||||
2. 使用一个包转发器，因此从客户端发送到负载均衡器 VIP 的请求在拥有客户端源 IP 地址的节点终止，而不被中间代理。
|
||||
|
||||
|
||||
第一类负载均衡器必须使用一种它和后端之间约定的协议来和真实的客户端 IP 通信，例如 HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 头，或者 [proxy 协议](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)。
|
||||
第一类负载均衡器必须使用一种它和后端之间约定的协议来和真实的客户端 IP 通信，例如 HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 头，或者 [proxy 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。
|
||||
第二类负载均衡器可以通过简单的在保存于 Service 的 `service.spec.healthCheckNodePort` 字段上创建一个 HTTP 健康检查点来使用上面描述的特性。
|
||||
|
||||
|
||||
@@ -394,6 +402,4 @@ $ kubectl delete deployment source-ip-app
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* 学习更多关于 [通过 services 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
* 学习更多关于 [负载均衡](/zh/docs/user-guide/load-balancer)
|
||||
|
||||
* 进一步学习 [通过 services 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
@@ -1,723 +0,0 @@
|
||||
---
|
||||
title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
|
||||
content_type: tutorial
|
||||
weight: 21
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 31
|
||||
title: "示例: 添加日志和指标到 PHP / Redis Guestbook 案例"
|
||||
---
|
||||
<!--
|
||||
title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
|
||||
reviewers:
|
||||
- sftim
|
||||
content_type: tutorial
|
||||
weight: 21
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 31
|
||||
title: "Example: Add logging and metrics to the PHP / Redis Guestbook example"
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components:
|
||||
|
||||
* A running instance of the [PHP Guestbook with Redis tutorial](/docs/tutorials/stateless-application/guestbook)
|
||||
* Elasticsearch and Kibana
|
||||
* Filebeat
|
||||
* Metricbeat
|
||||
* Packetbeat
|
||||
-->
|
||||
本教程建立在
|
||||
[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 教程之上。
|
||||
*Beats*，是 Elastic 出品的开源的轻量级日志、指标和网络数据采集器，
|
||||
将和 Guestbook 一同部署在 Kubernetes 集群中。
|
||||
Beats 收集、分析、索引数据到 Elasticsearch，使你可以用 Kibana 查看并分析得到的运营信息。
|
||||
本示例由以下内容组成：
|
||||
* [带 Redis 的 PHP Guestbook 教程](/zh/docs/tutorials/stateless-application/guestbook)
|
||||
的一个实例部署
|
||||
* Elasticsearch 和 Kibana
|
||||
* Filebeat
|
||||
* Metricbeat
|
||||
* Packetbeat
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!--
|
||||
* Start up the PHP Guestbook with Redis.
|
||||
* Install kube-state-metrics.
|
||||
* Create a Kubernetes Secret.
|
||||
* Deploy the Beats.
|
||||
* View dashboards of your logs and metrics.
|
||||
-->
|
||||
* 启动用 Redis 部署的 PHP Guestbook。
|
||||
* 安装 kube-state-metrics。
|
||||
* 创建 Kubernetes secret。
|
||||
* 部署 Beats。
|
||||
* 用仪表板查看日志和指标。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
{{< version-check >}}
|
||||
|
||||
<!--
|
||||
Additionally you need:
|
||||
|
||||
* A running deployment of the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.
|
||||
|
||||
* A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co),
|
||||
run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)
|
||||
on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
|
||||
-->
|
||||
此外，你还需要:
|
||||
|
||||
* 依照教程[使用 Redis 的 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook)得到的一套运行中的部署环境。
|
||||
* 一套运行中的 Elasticsearch 和 Kibana 部署环境。你可以使用 [Elastic 云中的Elasticsearch 服务](https://cloud.elastic.co)、在工作站或者服务器上运行此[下载文件](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)、或运行 [Elastic Helm Charts](https://github.com/elastic/helm-charts)。
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Start up the PHP Guestbook with Redis
|
||||
|
||||
This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. If you have the guestbook application running, then you can monitor that. If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps. Come back to this page when you have the guestbook running.
|
||||
-->
|
||||
## 启动用 Redis 部署的 PHP Guestbook {#start-up-the-php-guestbook-with-redis}
|
||||
|
||||
本教程建立在
|
||||
[使用 Redis 部署 PHP Guestbook](/zh/docs/tutorials/stateless-application/guestbook) 之上。
|
||||
如果你已经有一个运行的 Guestbook 应用程序，那就监控它。
|
||||
如果还没有，那就按照说明先部署 Guestbook ，但不要执行**清理**的步骤。
|
||||
当 Guestbook 运行起来后，再返回本页。
|
||||
|
||||
<!--
|
||||
## Add a Cluster role binding
|
||||
|
||||
Create a [cluster level role binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) so that you can deploy kube-state-metrics and the Beats at the cluster level (in kube-system).
|
||||
-->
|
||||
## 添加一个集群角色绑定 {#add-a-cluster-role-binding}
|
||||
|
||||
创建一个[集群范围的角色绑定](/zh/docs/reference/access-authn-authz/rbac/#rolebinding-和-clusterrolebinding)，
|
||||
以便你可以在集群范围（在 kube-system 中）部署 kube-state-metrics 和 Beats。
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding cluster-admin-binding \
|
||||
--clusterrole=cluster-admin --user=<your email associated with the k8s provider account>
|
||||
```
|
||||
|
||||
<!--
|
||||
## Install kube-state-metrics
|
||||
|
||||
Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics) is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects. Metricbeat reports these metrics. Add kube-state-metrics to the Kubernetes cluster that the guestbook is running in.
|
||||
-->
|
||||
### 安装 kube-state-metrics {#install-kube-state-metrics}
|
||||
|
||||
Kubernetes [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)
|
||||
是一个简单的服务，它侦听 Kubernetes API 服务器并生成对象状态的指标。
|
||||
Metricbeat 报告这些指标。
|
||||
添加 kube-state-metrics 到运行 Guestbook 的 Kubernetes 集群。
|
||||
|
||||
```shell
|
||||
git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
|
||||
kubectl apply -f kube-state-metrics/examples/standard
|
||||
```
|
||||
|
||||
<!--
|
||||
### Check to see if kube-state-metrics is running
|
||||
-->
|
||||
### 检查 kube-state-metrics 是否正在运行 {#check-to-see-if-kube-state-metrics-is-running}
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
|
||||
```
|
||||
|
||||
<!--
|
||||
Output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clone the Elastic examples GitHub repo
|
||||
-->
|
||||
## 从 GitHub 克隆 Elastic examples 库 {#clone-the-elastic-examples-github-repo}
|
||||
|
||||
```shell
|
||||
git clone https://github.com/elastic/examples.git
|
||||
```
|
||||
|
||||
<!--
|
||||
The rest of the commands will reference files in the `examples/beats-k8s-send-anywhere` directory, so change dir there:
|
||||
-->
|
||||
后续命令将引用目录 `examples/beats-k8s-send-anywhere` 中的文件，
|
||||
所以把目录切换过去。
|
||||
|
||||
```shell
|
||||
cd examples/beats-k8s-send-anywhere
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create a Kubernetes Secret
|
||||
A Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}} is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.
|
||||
|
||||
There are two sets of steps here, one for *self managed* Elasticsearch and Kibana (running on your servers or using the Elastic Helm Charts), and a second separate set for the *managed service* Elasticsearch Service in Elastic Cloud. Only create the secret for the type of Elasticsearch and Kibana system that you will use for this tutorial.
|
||||
-->
|
||||
## 创建 Kubernetes Secret {#create-a-kubernetes-secret}
|
||||
|
||||
Kubernetes {{< glossary_tooltip text="Secret" term_id="secret" >}}
|
||||
是包含少量敏感数据（类似密码、令牌、秘钥等）的对象。
|
||||
这类信息也可以放在 Pod 规格定义或者镜像中；
|
||||
但放在 Secret 对象中，能更好的控制它的使用方式，也能减少意外泄露的风险。
|
||||
|
||||
{{< note >}}
|
||||
这里有两套步骤，一套用于*自管理*的 Elasticsearch 和 Kibana（运行在你的服务器上或使用 Helm Charts），
|
||||
另一套用于在 Elastic 云服务中 *Managed service* 的 Elasticsearch 服务。
|
||||
在本教程中，只需要为 Elasticsearch 和 Kibana 系统创建 secret。
|
||||
{{< /note >}}
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="自管理" %}}
|
||||
|
||||
<!--
|
||||
### Self managed
|
||||
Switch to the **Managed service** tab if you are connecting to Elasticsearch Service in Elastic Cloud.
|
||||
|
||||
### Set the credentials
|
||||
There are four files to edit to create a k8s secret when you are connecting to self managed Elasticsearch and Kibana (self managed is effectively anything other than the managed Elasticsearch Service in Elastic Cloud). The files are:
|
||||
-->
|
||||
### 自管理系统 {#self-managed}
|
||||
|
||||
如果你使用 Elastic 云中的 Elasticsearch 服务，切换到 **Managed service** 标签页。
|
||||
|
||||
### 设置凭据 {#set-the-credentials}
|
||||
|
||||
当你使用自管理的 Elasticsearch 和 Kibana （对比托管于 Elastic 云中的 Elasticsearch 服务，自管理更有效率），
|
||||
创建 k8s secret 需要准备四个文件。这些文件是：
|
||||
|
||||
1. `ELASTICSEARCH_HOSTS`
|
||||
1. `ELASTICSEARCH_PASSWORD`
|
||||
1. `ELASTICSEARCH_USERNAME`
|
||||
1. `KIBANA_HOST`
|
||||
|
||||
<!--
|
||||
Set these with the information for your Elasticsearch cluster and your Kibana host. Here are some examples (also see [*this configuration*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897))
|
||||
-->
|
||||
为你的 Elasticsearch 集群和 Kibana 主机设置这些信息。这里是一些例子
|
||||
（另见[*此配置*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)）
|
||||
|
||||
#### `ELASTICSEARCH_HOSTS` {#elasticsearch-hosts}
|
||||
|
||||
<!--
|
||||
1. A nodeGroup from the Elastic Elasticsearch Helm Chart:
|
||||
-->
|
||||
1. 来自于 Elastic Elasticsearch Helm Chart 的节点组：
|
||||
|
||||
```
|
||||
["http://elasticsearch-master.default.svc.cluster.local:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
1. A single Elasticsearch node running on a Mac where your Beats are running in Docker for Mac:
|
||||
-->
|
||||
1. Mac 上的单节点的 Elasticsearch，Beats 运行在 Mac 的容器中：
|
||||
|
||||
```
|
||||
["http://host.docker.internal:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Two Elasticsearch nodes running in VMs or on physical hardware:
|
||||
-->
|
||||
1. 运行在虚拟机或物理机上的两个 Elasticsearch 节点
|
||||
|
||||
```
|
||||
["http://host1.example.com:9200", "http://host2.example.com:9200"]
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_HOSTS`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_HOSTS`
|
||||
```shell
|
||||
vi ELASTICSEARCH_HOSTS
|
||||
```
|
||||
|
||||
#### `ELASTICSEARCH_PASSWORD` {#elasticsearch-password}
|
||||
|
||||
<!--
|
||||
Just the password; no whitespace, quotes, or <>:
|
||||
-->
|
||||
只有密码；没有空格、引号、< 和 >：
|
||||
|
||||
```
|
||||
<yoursecretpassword>
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_PASSWORD`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_PASSWORD`：
|
||||
|
||||
```shell
|
||||
vi ELASTICSEARCH_PASSWORD
|
||||
```
|
||||
|
||||
#### `ELASTICSEARCH_USERNAME` {#elasticsearch-username}
|
||||
|
||||
<!--
|
||||
Just the username; no whitespace, quotes, or <>:
|
||||
-->
|
||||
只有用名；没有空格、引号、< 和 >：
|
||||
|
||||
<!--
|
||||
your ingest username for Elasticsearch
|
||||
-->
|
||||
```
|
||||
<为 Elasticsearch 注入的用户名>
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `ELASTICSEARCH_USERNAME`
|
||||
-->
|
||||
编辑 `ELASTICSEARCH_USERNAME`：
|
||||
|
||||
```shell
|
||||
vi ELASTICSEARCH_USERNAME
|
||||
```
|
||||
|
||||
#### `KIBANA_HOST` {#kibana-host}
|
||||
|
||||
<!--
|
||||
1. The Kibana instance from the Elastic Kibana Helm Chart. The subdomain `default` refers to the default namespace. If you have deployed the Helm Chart using a different namespace, then your subdomain will be different:
|
||||
-->
|
||||
1. 从 Elastic Kibana Helm Chart 安装的 Kibana 实例。子域 `default` 指默认的命名空间。如果你把 Helm Chart 指定部署到不同的命名空间，那子域会不同：
|
||||
|
||||
```
|
||||
"kibana-kibana.default.svc.cluster.local:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. A Kibana instance running on a Mac where your Beats are running in Docker for Mac:
|
||||
-->
|
||||
1. Mac 上的 Kibana 实例，Beats 运行于 Mac 的容器：
|
||||
|
||||
```
|
||||
"host.docker.internal:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Two Elasticsearch nodes running in VMs or on physical hardware:
|
||||
-->
|
||||
1. 运行于虚拟机或物理机上的两个 Elasticsearch 节点：
|
||||
|
||||
```
|
||||
"host1.example.com:5601"
|
||||
```
|
||||
|
||||
<!--
|
||||
Edit `KIBANA_HOST`
|
||||
-->
|
||||
编辑 `KIBANA_HOST`：
|
||||
|
||||
```shell
|
||||
vi KIBANA_HOST
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a Kubernetes secret
|
||||
This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
|
||||
-->
|
||||
### 创建 Kubernetes secret {#create-a-kubernetes-secret}
|
||||
|
||||
在上面编辑完的文件的基础上，本命令在 Kubernetes 系统范围的命名空间（kube-system）创建一个 secret。
|
||||
|
||||
```
|
||||
kubectl create secret generic dynamic-logging \
|
||||
--from-file=./ELASTICSEARCH_HOSTS \
|
||||
--from-file=./ELASTICSEARCH_PASSWORD \
|
||||
--from-file=./ELASTICSEARCH_USERNAME \
|
||||
--from-file=./KIBANA_HOST \
|
||||
--namespace=kube-system
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Managed service" %}}
|
||||
|
||||
<!--
|
||||
## Managed service
|
||||
This tab is for Elasticsearch Service in Elastic Cloud only, if you have already created a secret for a self managed Elasticsearch and Kibana deployment, then continue with [Deploy the Beats](#deploy-the-beats).
|
||||
### Set the credentials
|
||||
There are two files to edit to create a k8s secret when you are connecting to the managed Elasticsearch Service in Elastic Cloud. The files are:
|
||||
-->
|
||||
## Managed service {#managed-service}
|
||||
|
||||
本标签页只用于 Elastic 云 的 Elasticsearch 服务，如果你已经为自管理的 Elasticsearch 和 Kibana 创建了secret，请继续[部署 Beats](#deploy-the-beats)并继续。
|
||||
|
||||
### 设置凭据 {#set-the-credentials}
|
||||
|
||||
在 Elastic 云中的托管 Elasticsearch 服务中，为了创建 k8s secret，你需要先编辑两个文件。它们是：
|
||||
|
||||
1. `ELASTIC_CLOUD_AUTH`
|
||||
1. `ELASTIC_CLOUD_ID`
|
||||
|
||||
<!--
|
||||
Set these with the information provided to you from the Elasticsearch Service console when you created the deployment. Here are some examples:
|
||||
-->
|
||||
当你完成部署的时候，Elasticsearch 服务控制台会提供给你一些信息，用这些信息完成设置。
|
||||
这里是一些示例：
|
||||
|
||||
#### ELASTIC_CLOUD_ID {#elastic-cloud-id}
|
||||
|
||||
```
|
||||
devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
|
||||
```
|
||||
|
||||
#### ELASTIC_CLOUD_AUTH {#elastic-cloud-auth}
|
||||
|
||||
<!--
|
||||
Just the username, a colon (`:`), and the password, no whitespace or quotes:
|
||||
-->
|
||||
只要用户名；没有空格、引号、< 和 >：
|
||||
|
||||
```
|
||||
elastic:VFxJJf9Tjwer90wnfTghsn8w
|
||||
```
|
||||
|
||||
<!--
|
||||
### Edit the required files:
|
||||
-->
|
||||
### 编辑要求的文件 {#edit-the-required-files}
|
||||
```shell
|
||||
vi ELASTIC_CLOUD_ID
|
||||
vi ELASTIC_CLOUD_AUTH
|
||||
```
|
||||
|
||||
<!--
|
||||
### Create a Kubernetes secret
|
||||
This command creates a secret in the Kubernetes system level namespace (kube-system) based on the files you just edited:
|
||||
-->
|
||||
### 创建 Kubernetes secret {#create-a-kubernetes-secret}
|
||||
|
||||
基于上面刚编辑过的文件，在 Kubernetes 系统范围命名空间（kube-system）中，用下面命令创建一个的secret：
|
||||
|
||||
kubectl create secret generic dynamic-logging \
|
||||
--from-file=./ELASTIC_CLOUD_ID \
|
||||
--from-file=./ELASTIC_CLOUD_AUTH \
|
||||
--namespace=kube-system
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## Deploy the Beats
|
||||
Manifest files are provided for each Beat. These manifest files use the secret created earlier to configure the Beats to connect to your Elasticsearch and Kibana servers.
|
||||
|
||||
### About Filebeat
|
||||
Filebeat will collect logs from the Kubernetes nodes and the containers running in each pod running on those nodes. Filebeat is deployed as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}. Filebeat can autodiscover applications running in your Kubernetes cluster. At startup Filebeat scans existing containers and launches the proper configurations for them, then it will watch for new start/stop events.
|
||||
|
||||
Here is the autodiscover configuration that enables Filebeat to locate and parse Redis logs from the Redis containers deployed with the guestbook application. This configuration is in the file `filebeat-kubernetes.yaml`:
|
||||
-->
|
||||
## 部署 Beats {#deploy-the-beats}
|
||||
|
||||
为每一个 Beat 提供 清单文件。清单文件使用已创建的 secret 接入 Elasticsearch 和 Kibana 服务器。
|
||||
|
||||
### 关于 Filebeat {#about-filebeat}
|
||||
|
||||
Filebeat 收集日志，日志来源于 Kubernetes 节点以及这些节点上每一个 Pod 中的容器。Filebeat 部署为
|
||||
{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。
|
||||
Filebeat 支持自动发现 Kubernetes 集群中的应用。
|
||||
在启动时，Filebeat 扫描存量的容器，并为它们提供适当的配置，
|
||||
然后开始监听新的启动/中止信号。
|
||||
|
||||
下面是一个自动发现的配置，它支持 Filebeat 定位并分析来自于 Guestbook 应用部署的 Redis 容器的日志文件。
|
||||
下面的配置片段来自文件 `filebeat-kubernetes.yaml`：
|
||||
|
||||
```yaml
|
||||
- condition.contains:
|
||||
kubernetes.labels.app: redis
|
||||
config:
|
||||
- module: redis
|
||||
log:
|
||||
input:
|
||||
type: docker
|
||||
containers.ids:
|
||||
- ${data.kubernetes.container.id}
|
||||
slowlog:
|
||||
enabled: true
|
||||
var.hosts: ["${data.host}:${data.port}"]
|
||||
```
|
||||
|
||||
<!--
|
||||
This configures Filebeat to apply the Filebeat module `redis` when a container is detected with a label `app` containing the string `redis`. The redis module has the ability to collect the `log` stream from the container by using the docker input type (reading the file on the Kubernetes node associated with the STDOUT stream from this Redis container). Additionally, the module has the ability to collect Redis `slowlog` entries by connecting to the proper pod host and port, which is provided in the container metadata.
|
||||
|
||||
### Deploy Filebeat:
|
||||
-->
|
||||
|
||||
这样配置 Filebeat，当探测到容器拥有 `app` 标签，且值为 `redis`，那就启用 Filebeat 的 `redis` 模块。
|
||||
`redis` 模块可以根据 docker 的输入类型（在 Kubernetes 节点上读取和 Redis 容器的标准输出流关联的文件） ，从容器收集 `log` 流。
|
||||
另外，此模块还可以使用容器元数据中提供的配置信息，连到 Pod 适当的主机和端口，收集 Redis 的 `slowlog` 。
|
||||
|
||||
### 部署 Filebeat {#deploy-filebeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f filebeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
|
||||
```
|
||||
|
||||
<!--
|
||||
### About Metricbeat
|
||||
Metricbeat autodiscover is configured in the same way as Filebeat. Here is the Metricbeat autodiscover configuration for the Redis containers. This configuration is in the file `metricbeat-kubernetes.yaml`:
|
||||
-->
|
||||
### 关于 Metricbeat {#about-metricbeat}
|
||||
|
||||
Metricbeat 自动发现的配置方式与 Filebeat 完全相同。
|
||||
这里是针对 Redis 容器的 Metricbeat 自动发现配置。
|
||||
此配置片段来自于文件 `metricbeat-kubernetes.yaml`：
|
||||
|
||||
```yaml
|
||||
- condition.equals:
|
||||
kubernetes.labels.tier: backend
|
||||
config:
|
||||
- module: redis
|
||||
metricsets: ["info", "keyspace"]
|
||||
period: 10s
|
||||
|
||||
# Redis hosts
|
||||
hosts: ["${data.host}:${data.port}"]
|
||||
```
|
||||
<!--
|
||||
This configures Metricbeat to apply the Metricbeat module `redis` when a container is detected with a label `tier` equal to the string `backend`. The `redis` module has the ability to collect the `info` and `keyspace` metrics from the container by connecting to the proper pod host and port, which is provided in the container metadata.
|
||||
|
||||
### Deploy Metricbeat
|
||||
-->
|
||||
配置 Metricbeat，在探测到标签 `tier` 的值等于 `backend` 时，应用 Metricbeat 模块 `redis`。
|
||||
`redis` 模块可以获取容器元数据，连接到 Pod 适当的主机和端口，从 Pod 中收集指标 `info` 和 `keyspace`。
|
||||
|
||||
### 部署 Metricbeat {#deploy-metricbeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f metricbeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify2}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=metricbeat
|
||||
```
|
||||
|
||||
<!--
|
||||
### About Packetbeat
|
||||
Packetbeat configuration is different than Filebeat and Metricbeat. Rather than specify patterns to match against container labels the configuration is based on the protocols and port numbers involved. Shown below is a subset of the port numbers.
|
||||
|
||||
If you are running a service on a non-standard port add that port number to the appropriate type in `filebeat.yaml` and delete / create the Packetbeat DaemonSet.
|
||||
-->
|
||||
### 关于 Packetbeat {#about-packetbeat}
|
||||
|
||||
Packetbeat 的配置方式不同于 Filebeat 和 Metricbeat。
|
||||
相比于匹配容器标签的模式，它的配置基于相关协议和端口号。
|
||||
下面展示的是端口号的一个子集：
|
||||
|
||||
{{< note >}}
|
||||
如果你的服务运行在非标准的端口上，那就打开文件 `filebeat.yaml`，把这个端口号添加到合适的类型中，然后删除/启动 Packetbeat 的守护进程。
|
||||
{{< /note >}}
|
||||
|
||||
```yaml
|
||||
packetbeat.interfaces.device: any
|
||||
|
||||
packetbeat.protocols:
|
||||
- type: dns
|
||||
ports: [53]
|
||||
include_authorities: true
|
||||
include_additionals: true
|
||||
|
||||
- type: http
|
||||
ports: [80, 8000, 8080, 9200]
|
||||
|
||||
- type: mysql
|
||||
ports: [3306]
|
||||
|
||||
- type: redis
|
||||
ports: [6379]
|
||||
|
||||
packetbeat.flows:
|
||||
timeout: 30s
|
||||
period: 10s
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Deploy Packetbeat
|
||||
-->
|
||||
### 部署 Packetbeat {#deploy-packetbeat}
|
||||
|
||||
```shell
|
||||
kubectl create -f packetbeat-kubernetes.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
#### Verify
|
||||
-->
|
||||
#### 验证 {#verify3}
|
||||
|
||||
```shell
|
||||
kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
|
||||
```
|
||||
|
||||
<!--
|
||||
## View in Kibana
|
||||
|
||||
Open Kibana in your browser and then open the **Dashboard** application. In the search bar type Kubernetes and click on the Metricbeat dashboard for Kubernetes. This dashboard reports on the state of your Nodes, deployments, etc.
|
||||
|
||||
Search for Packetbeat on the Dashboard page, and view the Packetbeat overview.
|
||||
|
||||
Similarly, view dashboards for Apache and Redis. You will see dashboards for logs and metrics for each. The Apache Metricbeat dashboard will be blank. Look at the Apache Filebeat dashboard and scroll to the bottom to view the Apache error logs. This will tell you why there are no metrics available for Apache.
|
||||
|
||||
To enable Metricbeat to retrieve the Apache metrics, enable server-status by adding a ConfigMap including a mod-status configuration file and re-deploy the guestbook.
|
||||
|
||||
|
||||
## Scale your deployments and see new pods being monitored
|
||||
List the existing deployments:
|
||||
-->
|
||||
## 在 kibana 中浏览 {#view-in-kibana}
|
||||
|
||||
在浏览器中打开 kibana，再打开 **Dashboard**。
|
||||
在搜索栏中键入 Kubernetes，再点击 Metricbeat 的 Kubernetes Dashboard。
|
||||
此 Dashboard 展示节点状态、应用部署等。
|
||||
|
||||
在 Dashboard 页面，搜索 Packetbeat，并浏览 Packetbeat 概览信息。
|
||||
|
||||
同样地，浏览 Apache 和 Redis 的 Dashboard。
|
||||
可以看到日志和指标各自独立 Dashboard。
|
||||
Apache Metricbeat Dashboard 是空的。
|
||||
找到 Apache Filebeat Dashboard，拉到最下面，查看 Apache 的错误日志。
|
||||
日志会揭示出没有 Apache 指标的原因。
|
||||
|
||||
要让 metricbeat 得到 Apache 的指标，需要添加一个包含模块状态配置文件的 ConfigMap，并重新部署 Guestbook。
|
||||
|
||||
## 缩放部署规模，查看新 Pod 已被监控 {#scale-your-deployments-and-see-new-pods-being-monitored}
|
||||
|
||||
列出现有的 deployments：
|
||||
|
||||
```shell
|
||||
kubectl get deployments
|
||||
```
|
||||
|
||||
<!--
|
||||
The output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
frontend 3/3 3 3 3h27m
|
||||
redis-master 1/1 1 1 3h27m
|
||||
redis-slave 2/2 2 2 3h27m
|
||||
```
|
||||
|
||||
<!--
|
||||
Scale the frontend down to two pods:
|
||||
-->
|
||||
缩放前端到两个 Pod：
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=2 deployment/frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
The output:
|
||||
-->
|
||||
输出：
|
||||
|
||||
```
|
||||
deployment.extensions/frontend scaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Scale the frontend back up to three pods:
|
||||
-->
|
||||
将前端应用缩放回三个 Pod：
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=3 deployment/frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
## View the changes in Kibana
|
||||
See the screenshot, add the indicated filters and then add the columns to the view. You can see the ScalingReplicaSet entry that is marked, following from there to the top of the list of events shows the image being pulled, the volumes mounted, the pod starting, etc.
|
||||
|
||||
-->
|
||||
## 在 Kibana 中查看变化 {#view-the-chagnes-in-kibana}
|
||||
|
||||
参见屏幕截图，添加指定的过滤器，然后将列添加到视图。
|
||||
你可以看到，ScalingReplicaSet 被做了标记，从标记的点开始，到消息列表的顶部，展示了拉取的镜像、挂载的卷、启动的 Pod 等。
|
||||
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
<!--
|
||||
Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command.
|
||||
|
||||
1. Run the following commands to delete all Pods, Deployments, and Services.
|
||||
-->
|
||||
删除 Deployments 和 Services， 删除运行的 Pod。
|
||||
用标签功能在一个命令中删除多个资源。
|
||||
|
||||
1. 执行下列命令，删除所有的 Pod、Deployment 和 Services。
|
||||
|
||||
```shell
|
||||
kubectl delete deployment -l app=redis
|
||||
kubectl delete service -l app=redis
|
||||
kubectl delete deployment -l app=guestbook
|
||||
kubectl delete service -l app=guestbook
|
||||
kubectl delete -f filebeat-kubernetes.yaml
|
||||
kubectl delete -f metricbeat-kubernetes.yaml
|
||||
kubectl delete -f packetbeat-kubernetes.yaml
|
||||
kubectl delete secret dynamic-logging -n kube-system
|
||||
```
|
||||
<!--
|
||||
1. Query the list of Pods to verify that no Pods are running:
|
||||
-->
|
||||
2. 查询 Pod，以核实没有 Pod 还在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be this:
|
||||
-->
|
||||
响应应该是这样：
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn about [tools for monitoring resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* Read more about [logging architecture](/docs/concepts/cluster-administration/logging/)
|
||||
* Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/)
|
||||
* Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
-->
|
||||
* 了解[监控资源的工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* 进一步阅读[日志体系架构](/zh/docs/concepts/cluster-administration/logging/)
|
||||
* 进一步阅读[应用内省和调试](/zh/docs/tasks/debug-application-cluster/)
|
||||
* 进一步阅读[应用程序的故障排除](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
@@ -1,15 +1,16 @@
|
||||
---
|
||||
title: "示例：使用 Redis 部署 PHP 留言板应用程序"
|
||||
title: "示例：使用 MongoDB 部署 PHP 留言板应用程序"
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "无状态应用示例：基于 Redis 的 PHP Guestbook"
|
||||
title: "无状态应用示例：基于 MongoDB 的 PHP Guestbook"
|
||||
min-kubernetes-server-version: v1.14
|
||||
---
|
||||
|
||||
<!--
|
||||
title: "Example: Deploying PHP Guestbook application with Redis"
|
||||
title: "Example: Deploying PHP Guestbook application with MongoDB"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
@@ -17,25 +18,24 @@ weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "Stateless Example: PHP Guestbook with Redis"
|
||||
title: "Stateless Example: PHP Guestbook with MongoDB"
|
||||
min-kubernetes-server-version: v1.14
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This tutorial shows you how to build and deploy a simple, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/). This example consists of the following components:
|
||||
This tutorial shows you how to build and deploy a simple _(not production ready)_, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/). This example consists of the following components:
|
||||
-->
|
||||
本教程向您展示如何使用 Kubernetes 和 [Docker](https://www.docker.com/) 构建和部署
|
||||
一个简单的多层 web 应用程序。本例由以下组件组成：
|
||||
一个简单的_(非面向生产)的_多层 web 应用程序。本例由以下组件组成：
|
||||
|
||||
<!--
|
||||
* A single-instance [Redis](https://redis.io/) master to store guestbook entries
|
||||
* Multiple [replicated Redis](https://redis.io/topics/replication) instances to serve reads
|
||||
* A single-instance [MongoDB](https://www.mongodb.com/) to store guestbook entries
|
||||
* Multiple web frontend instances
|
||||
-->
|
||||
|
||||
* 单实例 [Redis](https://redis.io/) 主节点保存留言板条目
|
||||
* 多个[从 Redis](https://redis.io/topics/replication) 节点用来读取数据
|
||||
* 单实例 [MongoDB](https://www.mongodb.com/) 以保存留言板条目
|
||||
* 多个 web 前端实例
|
||||
|
||||
|
||||
@@ -45,15 +45,13 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica
|
||||
|
||||
|
||||
<!--
|
||||
* Start up a Redis master.
|
||||
* Start up Redis slaves.
|
||||
* Start up a Mongo database.
|
||||
* Start up the guestbook frontend.
|
||||
* Expose and view the Frontend Service.
|
||||
* Clean up.
|
||||
-->
|
||||
|
||||
* 启动 Redis 主节点。
|
||||
* 启动 Redis 从节点。
|
||||
* 启动 Mongo 数据库。
|
||||
* 启动留言板前端。
|
||||
* 公开并查看前端服务。
|
||||
* 清理。
|
||||
@@ -72,44 +70,50 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica
|
||||
<!-- lessoncontent -->
|
||||
|
||||
<!--
|
||||
## Start up the Redis Master
|
||||
## Start up the Mongo Database
|
||||
-->
|
||||
|
||||
## 启动 Redis 主节点
|
||||
## 启动 Mongo 数据库
|
||||
|
||||
<!--
|
||||
The guestbook application uses Redis to store its data. It writes its data to a Redis master instance and reads data from multiple Redis slave instances.
|
||||
The guestbook application uses MongoDB to store its data.
|
||||
-->
|
||||
留言板应用程序使用 Redis 存储数据。它将数据写入一个 Redis 主实例，并从多个 Redis 读取数据。
|
||||
留言板应用程序使用 MongoDB 存储数据。
|
||||
|
||||
<!--
|
||||
### Creating the Redis Master Deployment
|
||||
### Creating the Mongo Deployment
|
||||
-->
|
||||
|
||||
### 创建 Redis 主节点的 Deployment
|
||||
### 创建 Mongo 的 Deployment
|
||||
|
||||
<!--
|
||||
The manifest file, included below, specifies a Deployment controller that runs a single replica Redis master Pod.
|
||||
The manifest file, included below, specifies a Deployment controller that runs a single replica MongoDB Pod.
|
||||
-->
|
||||
下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 Redis 主节点 Pod 副本。
|
||||
下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 MongoDB Pod 副本。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
|
||||
{{< codenew file="application/guestbook/mongo-deployment.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Launch a terminal window in the directory you downloaded the manifest files.
|
||||
1. Apply the Redis Master Deployment from the `redis-master-deployment.yaml` file:
|
||||
1. Apply the MongoDB Deployment from the `mongo-deployment.yaml` file:
|
||||
-->
|
||||
1. 在下载清单文件的目录中启动终端窗口。
|
||||
2. 从 `redis-master-deployment.yaml` 文件中应用 Redis 主 Deployment：
|
||||
2. 从 `mongo-deployment.yaml` 文件中应用 MongoDB Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Query the list of Pods to verify that the Redis Master Pod is running:
|
||||
<!---
|
||||
for local testing of the content via relative file path
|
||||
kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
|
||||
-->
|
||||
3. 查询 Pod 列表以验证 Redis 主节点 Pod 是否正在运行：
|
||||
|
||||
|
||||
<!--
|
||||
1. Query the list of Pods to verify that the MongoDB Pod is running:
|
||||
-->
|
||||
3. 查询 Pod 列表以验证 MongoDB Pod 是否正在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
@@ -122,53 +126,49 @@ The manifest file, included below, specifies a Deployment controller that runs a
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis-master-1068406935-3lswp 1/1 Running 0 28s
|
||||
mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Run the following command to view the logs from the Redis Master Pod:
|
||||
1. Run the following command to view the logs from the MongoDB Deployment:
|
||||
-->
|
||||
4. 运行以下命令查看 Redis 主节点 Pod 中的日志：
|
||||
4. 运行以下命令查看 MongoDB Deployment 中的日志：
|
||||
|
||||
```shell
|
||||
kubectl logs -f POD-NAME
|
||||
kubectl logs -f deployment/mongo
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
Replace POD-NAME with the name of your Pod.
|
||||
-->
|
||||
将 POD-NAME 替换为您的 Pod 名称。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Creating the Redis Master Service
|
||||
### Creating the MongoDB Service
|
||||
-->
|
||||
|
||||
### 创建 Redis 主节点的服务
|
||||
### 创建 MongoDB 服务
|
||||
|
||||
<!--
|
||||
The guestbook application needs to communicate to the Redis master to write its data. You need to apply a [Service](/docs/concepts/services-networking/service/) to proxy the traffic to the Redis master Pod. A Service defines a policy to access the Pods.
|
||||
The guestbook application needs to communicate to the MongoDB to write its data. You need to apply a [Service](/docs/concepts/services-networking/service/) to proxy the traffic to the MongoDB Pod. A Service defines a policy to access the Pods.
|
||||
-->
|
||||
留言板应用程序需要往 Redis 主节点中写数据。因此，需要创建 [Service](/zh/docs/concepts/services-networking/service/) 来代理 Redis 主节点 Pod 的流量。Service 定义了访问 Pod 的策略。
|
||||
留言板应用程序需要往 MongoDB 中写数据。因此，需要创建 [Service](/zh/docs/concepts/services-networking/service/) 来代理 MongoDB Pod 的流量。Service 定义了访问 Pod 的策略。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
|
||||
{{< codenew file="application/guestbook/mongo-service.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Apply the Redis Master Service from the following `redis-master-service.yaml` file:
|
||||
1. Apply the MongoDB Service from the following `mongo-service.yaml` file:
|
||||
-->
|
||||
1. 使用下面的 `redis-master-service.yaml` 文件创建 Redis 主节点的服务：
|
||||
1. 使用下面的 `mongo-service.yaml` 文件创建 MongoDB 的服务：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Query the list of Services to verify that the Redis Master Service is running:
|
||||
<!---
|
||||
for local testing of the content via relative file path
|
||||
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
|
||||
-->
|
||||
2. 查询服务列表验证 Redis 主节点服务是否正在运行：
|
||||
|
||||
<!--
|
||||
1. Query the list of Services to verify that the MongoDB Service is running:
|
||||
-->
|
||||
2. 查询服务列表验证 MongoDB 服务是否正在运行：
|
||||
|
||||
```shell
|
||||
kubectl get service
|
||||
@@ -182,134 +182,26 @@ The guestbook application needs to communicate to the Redis master to write its
|
||||
```shell
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
|
||||
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 8s
|
||||
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 8s
|
||||
```
|
||||
|
||||
<!--
|
||||
This manifest file creates a Service named `mongo` with a set of labels that match the labels previously defined, so the Service routes network traffic to the MongoDB Pod.
|
||||
-->
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
This manifest file creates a Service named `redis-master` with a set of labels that match the labels previously defined, so the Service routes network traffic to the Redis master Pod.
|
||||
-->
|
||||
这个清单文件创建了一个名为 `Redis-master` 的 Service，其中包含一组与前面定义的标签匹配的标签，因此服务将网络流量路由到 Redis 主节点 Pod 上。
|
||||
|
||||
这个清单文件创建了一个名为 `mongo` 的 Service，其中包含一组与前面定义的标签匹配的标签，因此服务将网络流量路由到 MongoDB Pod 上。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Start up the Redis Slaves
|
||||
-->
|
||||
|
||||
## 启动 Redis 从节点
|
||||
|
||||
<!--
|
||||
Although the Redis master is a single pod, you can make it highly available to meet traffic demands by adding replica Redis slaves.
|
||||
-->
|
||||
尽管 Redis 主节点是一个单独的 pod，但是您可以通过添加 Redis 从节点的方式来使其高可用性，以满足流量需求。
|
||||
|
||||
<!--
|
||||
### Creating the Redis Slave Deployment
|
||||
-->
|
||||
|
||||
### 创建 Redis 从节点 Deployment
|
||||
|
||||
<!--
|
||||
Deployments scale based off of the configurations set in the manifest file. In this case, the Deployment object specifies two replicas.
|
||||
-->
|
||||
Deployments 根据清单文件中设置的配置进行伸缩。在这种情况下，Deployment 对象指定两个副本。
|
||||
|
||||
<!--
|
||||
If there are not any replicas running, this Deployment would start the two replicas on your container cluster. Conversely, if there are more than two replicas are running, it would scale down until two replicas are running.
|
||||
-->
|
||||
如果没有任何副本正在运行，则此 Deployment 将启动容器集群上的两个副本。相反，
|
||||
如果有两个以上的副本在运行，那么它的规模就会缩小，直到运行两个副本为止。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Apply the Redis Slave Deployment from the `redis-slave-deployment.yaml` file:
|
||||
-->
|
||||
1. 从 `redis-slave-deployment.yaml` 文件中应用 Redis Slave Deployment：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Query the list of Pods to verify that the Redis Slave Pods are running:
|
||||
-->
|
||||
2. 查询 Pod 列表以验证 Redis Slave Pod 正在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be similar to this:
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis-master-1068406935-3lswp 1/1 Running 0 1m
|
||||
redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s
|
||||
redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s
|
||||
```
|
||||
|
||||
<!--
|
||||
### Creating the Redis Slave Service
|
||||
-->
|
||||
|
||||
### 创建 Redis 从节点的 Service
|
||||
|
||||
<!--
|
||||
The guestbook application needs to communicate to Redis slaves to read data. To make the Redis slaves discoverable, you need to set up a Service. A Service provides transparent load balancing to a set of Pods.
|
||||
-->
|
||||
留言板应用程序需要从 Redis 从节点中读取数据。
|
||||
为了便于 Redis 从节点可发现，
|
||||
您需要设置一个 Service。Service 为一组 Pod 提供负载均衡。
|
||||
|
||||
{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
|
||||
|
||||
<!--
|
||||
1. Apply the Redis Slave Service from the following `redis-slave-service.yaml` file:
|
||||
-->
|
||||
1. 从以下 `redis-slave-service.yaml` 文件应用 Redis Slave 服务：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Query the list of Services to verify that the Redis slave service is running:
|
||||
-->
|
||||
2. 查询服务列表以验证 Redis 在服务是否正在运行：
|
||||
|
||||
```shell
|
||||
kubectl get services
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be similar to this:
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2m
|
||||
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 1m
|
||||
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 6s
|
||||
```
|
||||
|
||||
<!--
|
||||
## Set up and Expose the Guestbook Frontend
|
||||
-->
|
||||
|
||||
## 设置并公开留言板前端
|
||||
|
||||
<!--
|
||||
The guestbook application has a web frontend serving the HTTP requests written in PHP. It is configured to connect to the `redis-master` Service for write requests and the `redis-slave` service for Read requests.
|
||||
-->
|
||||
<!--
|
||||
The guestbook application has a web frontend serving the HTTP requests written in PHP. It is configured to connect to the `mongo` Service to store Guestbook entries.
|
||||
-->
|
||||
留言板应用程序有一个 web 前端，服务于用 PHP 编写的 HTTP 请求。
|
||||
它被配置为连接到写请求的 `redis-master` 服务和读请求的 `redis-slave` 服务。
|
||||
它被配置为连接到 `mongo` 服务以存储留言版条目。
|
||||
|
||||
<!--
|
||||
### Creating the Guestbook Frontend Deployment
|
||||
@@ -328,13 +220,18 @@ The guestbook application has a web frontend serving the HTTP requests written i
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
|
||||
```
|
||||
|
||||
<!---
|
||||
for local testing of the content via relative file path
|
||||
kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
|
||||
-->
|
||||
|
||||
<!--
|
||||
1. Query the list of Pods to verify that the three frontend replicas are running:
|
||||
-->
|
||||
2. 查询 Pod 列表，验证三个前端副本是否正在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=guestbook -l tier=frontend
|
||||
kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -356,24 +253,22 @@ The guestbook application has a web frontend serving the HTTP requests written i
|
||||
### 创建前端服务
|
||||
|
||||
<!--
|
||||
The `redis-slave` and `redis-master` Services you applied are only accessible within the container cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster.
|
||||
The `mongo` Services you applied is only accessible within the Kubernetes cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster.
|
||||
-->
|
||||
应用的 `redis-slave` 和 `redis-master` 服务只能在容器集群中访问，因为服务的默认类型是
|
||||
[ClusterIP](/zh/docs/concepts/Services-networking/Service/#publishingservices-Service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。
|
||||
应用的 `mongo` 服务只能在 Kubernetes 集群中访问，因为服务的默认类型是
|
||||
[ClusterIP](/zh/docs/concepts/services-networking/service/#publishing-services---service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。
|
||||
|
||||
<!--
|
||||
If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the container cluster. Minikube can only expose Services through `NodePort`.
|
||||
If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the Kubernetes cluster. However a Kubernetes user you can use `kubectl port-forward` to access the service even though it uses a `ClusterIP`.
|
||||
-->
|
||||
如果您希望客人能够访问您的留言板，您必须将前端服务配置为外部可见的，以便客户机可以从容器集群之外请求服务。Minikube 只能通过 `NodePort` 公开服务。
|
||||
如果您希望访客能够访问您的留言板，您必须将前端服务配置为外部可见的，以便客户端可以从 Kubernetes 集群之外请求服务。然而即便使用了 `ClusterIP` Kubernets 用户仍可以通过 `kubectl port-forwart` 访问服务。
|
||||
|
||||
<!--
|
||||
Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, uncomment `type: LoadBalancer`.
|
||||
-->
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, simply delete or comment out `type: NodePort`, and uncomment `type: LoadBalancer`.
|
||||
-->
|
||||
一些云提供商，如 Google Compute Engine 或 Google Kubernetes Engine，支持外部负载均衡器。如果您的云提供商支持负载均衡器，并且您希望使用它，
|
||||
只需删除或注释掉 `type: NodePort`，并取消注释 `type: LoadBalancer` 即可。
|
||||
|
||||
只需取消注释 `type: LoadBalancer` 即可。
|
||||
{{< /note >}}
|
||||
|
||||
{{< codenew file="application/guestbook/frontend-service.yaml" >}}
|
||||
@@ -387,6 +282,11 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
|
||||
```
|
||||
|
||||
<!---
|
||||
for local testing of the content via relative file path
|
||||
kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
|
||||
-->
|
||||
|
||||
<!--
|
||||
1. Query the list of Services to verify that the frontend Service is running:
|
||||
-->
|
||||
@@ -403,30 +303,24 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend NodePort 10.0.0.112 <none> 80:31323/TCP 6s
|
||||
frontend ClusterIP 10.0.0.112 <none> 80/TCP 6s
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
|
||||
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 2m
|
||||
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 1m
|
||||
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 2m
|
||||
```
|
||||
|
||||
<!--
|
||||
### Viewing the Frontend Service via `NodePort`
|
||||
### Viewing the Frontend Service via `kubectl port-forward`
|
||||
-->
|
||||
|
||||
### 通过 `NodePort` 查看前端服务
|
||||
### 通过 `kubectl port-forward` 查看前端服务
|
||||
|
||||
<!--
|
||||
If you deployed this application to Minikube or a local cluster, you need to find the IP address to view your Guestbook.
|
||||
1. Run the following command to forward port `8080` on your local machine to port `80` on the service.
|
||||
-->
|
||||
如果您将此应用程序部署到 Minikube 或本地集群，您需要找到 IP 地址来查看您的留言板。
|
||||
|
||||
<!--
|
||||
1. Run the following command to get the IP address for the frontend Service.
|
||||
-->
|
||||
1. 运行以下命令获取前端服务的 IP 地址。
|
||||
1. 运行以下命令将本机的 `8080` 端口转发到服务的 `80` 端口。
|
||||
|
||||
```shell
|
||||
minikube service frontend --url
|
||||
kubectl port-forward svc/frontend 8080:80
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -435,13 +329,14 @@ If you deployed this application to Minikube or a local cluster, you need to fin
|
||||
响应应该与此类似：
|
||||
|
||||
```
|
||||
http://192.168.99.100:31323
|
||||
Forwarding from 127.0.0.1:8080 -> 80
|
||||
Forwarding from [::1]:8080 -> 80
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Copy the IP address, and load the page in your browser to view your guestbook.
|
||||
1. load the page [http://localhost:8080](http://localhost:8080) in your browser to view your guestbook.
|
||||
-->
|
||||
2. 复制 IP 地址，然后在浏览器中加载页面以查看留言板。
|
||||
2. 在浏览器中加载 [http://localhost:8080](http://localhost:8080) 页面以查看留言板。
|
||||
|
||||
<!--
|
||||
### Viewing the Frontend Service via `LoadBalancer`
|
||||
@@ -519,9 +414,7 @@ Scaling up or down is easy because your servers are defined as a Service that us
|
||||
frontend-3823415956-k22zn 1/1 Running 0 54m
|
||||
frontend-3823415956-w9gbt 1/1 Running 0 54m
|
||||
frontend-3823415956-x2pld 1/1 Running 0 5s
|
||||
redis-master-1068406935-3lswp 1/1 Running 0 56m
|
||||
redis-slave-2005841000-fpvqc 1/1 Running 0 55m
|
||||
redis-slave-2005841000-phfv9 1/1 Running 0 55m
|
||||
mongo-1068406935-3lswp 1/1 Running 0 56m
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -551,9 +444,7 @@ Scaling up or down is easy because your servers are defined as a Service that us
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-3823415956-k22zn 1/1 Running 0 1h
|
||||
frontend-3823415956-w9gbt 1/1 Running 0 1h
|
||||
redis-master-1068406935-3lswp 1/1 Running 0 1h
|
||||
redis-slave-2005841000-fpvqc 1/1 Running 0 1h
|
||||
redis-slave-2005841000-phfv9 1/1 Running 0 1h
|
||||
mongo-1068406935-3lswp 1/1 Running 0 1h
|
||||
```
|
||||
|
||||
|
||||
@@ -569,13 +460,13 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
||||
<!--
|
||||
1. Run the following commands to delete all Pods, Deployments, and Services.
|
||||
-->
|
||||
5. 运行以下命令以删除所有 Pod，Deployments 和 Services。
|
||||
1. 运行以下命令以删除所有 Pod，Deployments 和 Services。
|
||||
|
||||
```shell
|
||||
kubectl delete deployment -l app=redis
|
||||
kubectl delete service -l app=redis
|
||||
kubectl delete deployment -l app=guestbook
|
||||
kubectl delete service -l app=guestbook
|
||||
kubectl delete deployment -l app.kubernetes.io/name=mongo
|
||||
kubectl delete service -l app.kubernetes.io/name=mongo
|
||||
kubectl delete deployment -l app.kubernetes.io/name=guestbook
|
||||
kubectl delete service -l app.kubernetes.io/name=guestbook
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -584,10 +475,8 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
||||
响应应该是：
|
||||
|
||||
```
|
||||
deployment.apps "redis-master" deleted
|
||||
deployment.apps "redis-slave" deleted
|
||||
service "redis-master" deleted
|
||||
service "redis-slave" deleted
|
||||
deployment.apps "mongo" deleted
|
||||
service "mongo" deleted
|
||||
deployment.apps "frontend" deleted
|
||||
service "frontend" deleted
|
||||
```
|
||||
@@ -595,7 +484,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
||||
<!--
|
||||
1. Query the list of Pods to verify that no Pods are running:
|
||||
-->
|
||||
6. 查询 Pod 列表，确认没有 Pod 在运行：
|
||||
2. 查询 Pod 列表，确认没有 Pod 在运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
@@ -616,15 +505,12 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
||||
|
||||
|
||||
<!--
|
||||
* Add [ELK logging and monitoring](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/) to your Guestbook application
|
||||
* Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials
|
||||
* Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)
|
||||
* Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/)
|
||||
* Read more about [Managing Resources](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)
|
||||
-->
|
||||
|
||||
* 为 Guestbook 应用添加
|
||||
[ELK 日志与监控](/zh/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
|
||||
* 完成 [Kubernetes Basics](/zh/docs/tutorials/kubernetes-basics/) 交互式教程
|
||||
* 使用 Kubernetes 创建一个博客，使用 [MySQL 和 Wordpress 的持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)
|
||||
* 阅读更多关于[连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
Reference in New Issue
Block a user