Merge pull request #23004 from tengqm/zh-links-concepts-8
[zh] Fix links in concepts section (8/last)
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
bb7c4de5f8
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "集群管理"
|
||||
title: 集群管理
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
|
|
@ -58,7 +58,7 @@ Before choosing a guide, here are some considerations:
|
|||
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
|
||||
latter, choose an actively-developed distro. Some distros only use binary releases, but
|
||||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
|
||||
- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
|
||||
-->
|
||||
- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
|
||||
- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？
|
||||
|
|
@ -66,7 +66,7 @@ Before choosing a guide, here are some considerations:
|
|||
- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
|
||||
- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）**上运行？
|
||||
- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/admin/cluster-components)。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
|
||||
|
||||
<!--
|
||||
## Managing a cluster
|
||||
|
|
@ -82,7 +82,7 @@ Before choosing a guide, here are some considerations:
|
|||
* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题：
|
||||
创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。
|
||||
|
||||
* 学习如何[管理节点](/zh/docs/concepts/nodes/node/)。
|
||||
* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。
|
||||
|
||||
* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。
|
||||
|
||||
|
|
@ -101,12 +101,12 @@ Before choosing a guide, here are some considerations:
|
|||
## 保护集群
|
||||
|
||||
* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
|
||||
* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [鉴权](/zh/docs/admin/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
|
||||
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
|
||||
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。
|
||||
|
||||
<!--
|
||||
|
|
@ -118,9 +118,9 @@ Before choosing a guide, here are some considerations:
|
|||
-->
|
||||
### 保护 kubelet
|
||||
|
||||
* [主控节点通信](/zh/docs/concepts/cluster-administration/master-node-communication/)
|
||||
* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 认证/授权](/zh/docs/admin/kubelet-authentication-authorization/)
|
||||
* [Kubelet 认证/授权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
|
||||
<!--
|
||||
## Optional Cluster Services
|
||||
|
|
|
|||
|
|
@ -1,12 +1,10 @@
|
|||
---
|
||||
|
||||
title: 安装扩展（Addons）
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
<!--
|
||||
Add-ons extend the functionality of Kubernetes.
|
||||
|
||||
|
|
@ -14,15 +12,11 @@ This page lists some of the available add-ons and links to their respective inst
|
|||
|
||||
Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
|
||||
-->
|
||||
|
||||
Add-ons 扩展了 Kubernetes 的功能。
|
||||
|
||||
本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。
|
||||
|
||||
每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
|
||||
|
||||
|
||||
|
||||
每个 Add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -45,33 +39,50 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
-->
|
||||
|
||||
## 网络和网络策略
|
||||
|
||||
* [ACI](https://www.github.com/noironetworks/aci-containers) 通过 Cisco ACI 提供集成的容器网络和安全网络。
|
||||
* [Calico](https://docs.projectcalico.org/v3.11/getting-started/kubernetes/installation/calico) 是一个安全的 L3 网络和网络策略提供者。
|
||||
* [Calico](https://docs.projectcalico.org/v3.11/getting-started/kubernetes/installation/calico)
|
||||
是一个安全的 L3 网络和网络策略驱动。
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico，提供网络和网络策略。
|
||||
* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件，能够透明的实施 HTTP/API/L7 策略。同时支持路由（routing）和叠加/封装（overlay/encapsulation）模式。
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。
|
||||
* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
|
||||
* 基于 [Tungsten Fabric](https://tungsten.io) 的 [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)，是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统（例如 Kubernetes、OpenShift、OpenStack和Mesos）集成在一起，并为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。
|
||||
* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件，能够透明的实施 HTTP/API/L7 策略。
|
||||
同时支持路由（routing）和覆盖/封装（overlay/encapsulation）模式。
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，
|
||||
例如：Flannel、Calico、Canal、Romana 或者 Weave。
|
||||
* [Contiv](https://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的覆盖网络，
|
||||
经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](https://github.com/contiv)。
|
||||
[安装工具](https://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
|
||||
* 基于 [Tungsten Fabric](https://tungsten.io) 的
|
||||
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)
|
||||
是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统
|
||||
（例如 Kubernetes、OpenShift、OpenStack和Mesos）集成在一起，
|
||||
为虚拟机、容器或 Pod 以及裸机工作负载提供了隔离模式。
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml)
|
||||
是一个可以用于 Kubernetes 的 overlay 网络提供者。
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) 是为 kubernetes 提供复合网络解决方案的网络组件。
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) 是一个多插件，可在 Kubernetes 中提供多种网络支持，以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel），而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件（ NCP ）提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。
|
||||
* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) 是一个多插件，可在 Kubernetes 中提供多种网络支持，
|
||||
以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel），
|
||||
而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 容器插件（NCP）
|
||||
提供了 VMware NSX-T 与容器协调器（例如 Kubernetes）之间的集成，以及 NSX-T 与基于容器的
|
||||
CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)
|
||||
是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。
|
||||
* [Romana](https://romana.io) 是一个 pod 网络的第三层解决方案，并支持[
|
||||
NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。
|
||||
Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)
|
||||
提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
|
||||
|
||||
<!--
|
||||
## Service Discovery
|
||||
|
||||
* [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods.
|
||||
-->
|
||||
|
||||
## 服务发现
|
||||
|
||||
* [CoreDNS](https://coredns.io) 是一种灵活的，可扩展的 DNS 服务器，可以[安装](https://github.com/coredns/deployment/tree/master/kubernetes)为集群内的 Pod 提供 DNS 服务。
|
||||
* [CoreDNS](https://coredns.io) 是一种灵活的，可扩展的 DNS 服务器，可以
|
||||
[安装](https://github.com/coredns/deployment/tree/master/kubernetes)为集群内的 Pod 提供 DNS 服务。
|
||||
|
||||
<!--
|
||||
## Visualization & Control
|
||||
|
|
@ -79,22 +90,22 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes.
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself.
|
||||
-->
|
||||
|
||||
## 可视化管理
|
||||
|
||||
|
||||
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services 等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。
|
||||
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 Web 控制台界面。
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，
|
||||
用于查看你的容器、Pod、服务等。请和一个 [Weave Cloud 账号](https://cloud.weave.works/) 一起使用，
|
||||
或者自己运行 UI。
|
||||
|
||||
<!--
|
||||
## Infrastructure
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
|
||||
-->
|
||||
|
||||
## 基础设施
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机集群上。
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes
|
||||
运行虚拟机的 add-ons。通常运行在裸机集群上。
|
||||
|
||||
<!--
|
||||
## Legacy Add-ons
|
||||
|
|
@ -103,7 +114,6 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht
|
|||
|
||||
Well-maintained ones should be linked to here. PRs welcome!
|
||||
-->
|
||||
|
||||
## 遗留 Add-ons
|
||||
|
||||
还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
---
|
||||
cn-approvers:
|
||||
- lichuqiang
|
||||
title: 证书
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Certificates
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -13,13 +15,9 @@ weight: 20
|
|||
When using client certificate authentication, you can generate certificates
|
||||
manually through `easyrsa`, `openssl` or `cfssl`.
|
||||
-->
|
||||
|
||||
当使用客户端证书进行认证时，用户可以使用现有部署脚本，或者通过 `easyrsa`、`openssl` 或
|
||||
`cfssl` 手动生成证书。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
### easyrsa
|
||||
|
|
@ -27,7 +25,6 @@ manually through `easyrsa`, `openssl` or `cfssl`.
|
|||
<!--
|
||||
**easyrsa** can manually generate certificates for your cluster.
|
||||
-->
|
||||
|
||||
使用 **easyrsa** 能够手动地为集群生成证书。
|
||||
|
||||
<!--
|
||||
|
|
@ -67,22 +64,30 @@ manually through `easyrsa`, `openssl` or `cfssl`.
|
|||
--tls-private-key-file=/yourdirectory/server.key
|
||||
-->
|
||||
|
||||
1. 下载、解压并初始化 easyrsa3 的补丁版本。
|
||||
1. 下载、解压并初始化 easyrsa3 的补丁版本。
|
||||
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
1. 生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN）
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
```
|
||||
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
1. 生成服务器证书和密钥。
|
||||
参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP`
|
||||
通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range` 同时用于
|
||||
API 服务器和控制器管理器组件。 `--days` 参数用于设置证书的有效期限。
|
||||
下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
1. 生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN）
|
||||
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
||||
```
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
```
|
||||
|
||||
1. 生成服务器证书和密钥。
|
||||
参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。
|
||||
`MASTER_CLUSTER_IP` 通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，
|
||||
`--service-cluster-ip-range` 同时用于 API 服务器和控制器管理器组件。
|
||||
`--days` 参数用于设置证书的有效期限。
|
||||
下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
|
||||
```
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
||||
"IP:${MASTER_CLUSTER_IP},"\
|
||||
"DNS:kubernetes,"\
|
||||
"DNS:kubernetes.default,"\
|
||||
|
|
@ -91,12 +96,17 @@ manually through `easyrsa`, `openssl` or `cfssl`.
|
|||
"DNS:kubernetes.default.svc.cluster.local" \
|
||||
--days=10000 \
|
||||
build-server-full server nopass
|
||||
1. 拷贝 `pki/ca.crt`、 `pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。
|
||||
1. 填充并在 API 服务器的启动参数中添加以下参数：
|
||||
```
|
||||
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
1. 拷贝 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。
|
||||
|
||||
1. 填充并在 API 服务器的启动参数中添加以下参数：
|
||||
|
||||
```
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
```
|
||||
|
||||
### openssl
|
||||
|
||||
|
|
@ -168,69 +178,87 @@ manually through `easyrsa`, `openssl` or `cfssl`.
|
|||
|
||||
使用 **openssl** 能够手动地为集群生成证书。
|
||||
|
||||
1. 生成密钥位数为 2048 的 ca.key：
|
||||
1. 生成密钥位数为 2048 的 ca.key：
|
||||
|
||||
openssl genrsa -out ca.key 2048
|
||||
1. 依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）：
|
||||
```
|
||||
openssl genrsa -out ca.key 2048
|
||||
```
|
||||
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
1. 生成密钥位数为 2048 的 server.key：
|
||||
1. 依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）：
|
||||
|
||||
openssl genrsa -out server.key 2048
|
||||
1. 创建用于生成证书签名请求（CSR）的配置文件。
|
||||
确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`）
|
||||
替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
|
||||
(service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
```
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
```
|
||||
|
||||
[ req ]
|
||||
default_bits = 2048
|
||||
prompt = no
|
||||
default_md = sha256
|
||||
req_extensions = req_ext
|
||||
distinguished_name = dn
|
||||
1. 生成密钥位数为 2048 的 server.key：
|
||||
|
||||
[ dn ]
|
||||
C = <country>
|
||||
ST = <state>
|
||||
L = <city>
|
||||
O = <organization>
|
||||
OU = <organization unit>
|
||||
CN = <MASTER_IP>
|
||||
```
|
||||
openssl genrsa -out server.key 2048
|
||||
```
|
||||
1. 创建用于生成证书签名请求（CSR）的配置文件。
|
||||
确保在将其保存至文件（如 `csr.conf`）之前将尖括号标记的值（如 `<MASTER_IP>`）
|
||||
替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
|
||||
(service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
|
||||
[ req_ext ]
|
||||
subjectAltName = @alt_names
|
||||
```
|
||||
[ req ]
|
||||
default_bits = 2048
|
||||
prompt = no
|
||||
default_md = sha256
|
||||
req_extensions = req_ext
|
||||
distinguished_name = dn
|
||||
|
||||
[ alt_names ]
|
||||
DNS.1 = kubernetes
|
||||
DNS.2 = kubernetes.default
|
||||
DNS.3 = kubernetes.default.svc
|
||||
DNS.4 = kubernetes.default.svc.cluster
|
||||
DNS.5 = kubernetes.default.svc.cluster.local
|
||||
IP.1 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
[ dn ]
|
||||
C = <国家>
|
||||
ST = <州/省>
|
||||
L = <市>
|
||||
O = <组织>
|
||||
OU = <部门>
|
||||
CN = <MASTER_IP>
|
||||
|
||||
[ v3_ext ]
|
||||
authorityKeyIdentifier=keyid,issuer:always
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=keyEncipherment,dataEncipherment
|
||||
extendedKeyUsage=serverAuth,clientAuth
|
||||
subjectAltName=@alt_names
|
||||
1. 基于配置文件生成证书签名请求：
|
||||
[ req_ext ]
|
||||
subjectAltName = @alt_names
|
||||
|
||||
openssl req -new -key server.key -out server.csr -config csr.conf
|
||||
1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书：
|
||||
[ alt_names ]
|
||||
DNS.1 = kubernetes
|
||||
DNS.2 = kubernetes.default
|
||||
DNS.3 = kubernetes.default.svc
|
||||
DNS.4 = kubernetes.default.svc.cluster
|
||||
DNS.5 = kubernetes.default.svc.cluster.local
|
||||
IP.1 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||
-CAcreateserial -out server.crt -days 10000 \
|
||||
-extensions v3_ext -extfile csr.conf
|
||||
1. 查看证书：
|
||||
[ v3_ext ]
|
||||
authorityKeyIdentifier=keyid,issuer:always
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=keyEncipherment,dataEncipherment
|
||||
extendedKeyUsage=serverAuth,clientAuth
|
||||
subjectAltName=@alt_names
|
||||
```
|
||||
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
1. 基于配置文件生成证书签名请求：
|
||||
|
||||
```
|
||||
openssl req -new -key server.key -out server.csr -config csr.conf
|
||||
```
|
||||
|
||||
1. 使用 ca.key、ca.crt 和 server.csr 生成服务器证书：
|
||||
|
||||
```
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||
-CAcreateserial -out server.crt -days 10000 \
|
||||
-extensions v3_ext -extfile csr.conf
|
||||
```
|
||||
|
||||
1. 查看证书：
|
||||
|
||||
```
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
```
|
||||
|
||||
<!--
|
||||
Finally, add the same parameters into the API server start parameters.
|
||||
-->
|
||||
|
||||
最后，添加同样的参数到 API 服务器的启动参数中。
|
||||
|
||||
### cfssl
|
||||
|
|
@ -238,8 +266,7 @@ Finally, add the same parameters into the API server start parameters.
|
|||
<!--
|
||||
**cfssl** is another tool for certificate generation.
|
||||
-->
|
||||
|
||||
**cfssl** 是另一种用来生成证书的工具。
|
||||
**cfssl** 是用来生成证书的另一种工具。
|
||||
|
||||
<!--
|
||||
1. Download, unpack and prepare the command line tools as shown below.
|
||||
|
|
@ -337,97 +364,115 @@ Finally, add the same parameters into the API server start parameters.
|
|||
--config=ca-config.json -profile=kubernetes \
|
||||
server-csr.json | ../cfssljson -bare server
|
||||
-->
|
||||
1. 按如下所示的方式下载、解压并准备命令行工具。
|
||||
注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。
|
||||
|
||||
1. 按如下所示的方式下载、解压并准备命令行工具。
|
||||
注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。
|
||||
```
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
|
||||
chmod +x cfssl
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
|
||||
chmod +x cfssljson
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
|
||||
chmod +x cfssl-certinfo
|
||||
```
|
||||
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
|
||||
chmod +x cfssl
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
|
||||
chmod +x cfssljson
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
|
||||
chmod +x cfssl-certinfo
|
||||
1. 创建目录来存放物料，并初始化 cfssl：
|
||||
1. 创建目录来存放物料，并初始化 cfssl：
|
||||
|
||||
mkdir cert
|
||||
cd cert
|
||||
../cfssl print-defaults config > config.json
|
||||
../cfssl print-defaults csr > csr.json
|
||||
1. 创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`：
|
||||
```
|
||||
mkdir cert
|
||||
cd cert
|
||||
../cfssl print-defaults config > config.json
|
||||
../cfssl print-defaults csr > csr.json
|
||||
```
|
||||
|
||||
{
|
||||
"signing": {
|
||||
"default": {
|
||||
"expiry": "8760h"
|
||||
},
|
||||
"profiles": {
|
||||
"kubernetes": {
|
||||
"usages": [
|
||||
"signing",
|
||||
"key encipherment",
|
||||
"server auth",
|
||||
"client auth"
|
||||
],
|
||||
"expiry": "8760h"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
1. 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。
|
||||
确保将尖括号标记的值替换为你想使用的真实值。
|
||||
1. 创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`：
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names":[{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）：
|
||||
```
|
||||
{
|
||||
"signing": {
|
||||
"default": {
|
||||
"expiry": "8760h"
|
||||
},
|
||||
"profiles": {
|
||||
"kubernetes": {
|
||||
"usages": [
|
||||
"signing",
|
||||
"key encipherment",
|
||||
"server auth",
|
||||
"client auth"
|
||||
],
|
||||
"expiry": "8760h"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||
1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。
|
||||
确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的
|
||||
API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
1. 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。
|
||||
确保将尖括号标记的值替换为你想使用的真实值。
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"hosts": [
|
||||
"127.0.0.1",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. 为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem`
|
||||
和 `server.pem` 中：
|
||||
```
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names":[{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
||||
1. 生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）：
|
||||
|
||||
```
|
||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||
```
|
||||
|
||||
1. 按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。
|
||||
确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的
|
||||
API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
|
||||
|
||||
```
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"hosts": [
|
||||
"127.0.0.1",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
1. 为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem`
|
||||
和 `server.pem` 中：
|
||||
|
||||
```
|
||||
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
||||
--config=ca-config.json -profile=kubernetes \
|
||||
server-csr.json | ../cfssljson -bare server
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
## Distributing Self-Signed CA Certificate
|
||||
|
|
@ -439,7 +484,6 @@ refresh the local list for valid certificates.
|
|||
|
||||
On each client, perform the following operations:
|
||||
-->
|
||||
|
||||
## 分发自签名 CA 证书
|
||||
|
||||
客户端节点可能拒绝承认自签名 CA 证书有效。
|
||||
|
|
@ -467,10 +511,9 @@ You can use the `certificates.k8s.io` API to provision
|
|||
x509 certificates to use for authentication as documented
|
||||
[here](/docs/tasks/tls/managing-tls-in-a-cluster).
|
||||
-->
|
||||
|
||||
## 证书 API
|
||||
|
||||
您可以按照[这里](/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式，
|
||||
您可以按照[这里](/zh/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式，
|
||||
使用 `certificates.k8s.io` API 来准备 x509 证书，用于认证。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,11 +5,9 @@ weight: 30
|
|||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Cloud Providers
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -28,7 +26,8 @@ kubeadm has configuration options to specify configuration information for cloud
|
|||
in-tree cloud provider can be configured using kubeadm as shown below:
|
||||
-->
|
||||
### kubeadm
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 是创建 kubernetes 集群的一种流行选择。
|
||||
|
||||
[kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 是创建 kubernetes 集群的一种流行选择。
|
||||
kubeadm 通过提供配置选项来指定云驱动的配置信息。例如，一个典型的适用于“树内”云驱动的 kubeadm 配置如下：
|
||||
|
||||
```yaml
|
||||
|
|
@ -68,9 +67,14 @@ for the [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager]
|
|||
For all external cloud providers, please follow the instructions on the individual repositories,
|
||||
which are listed under their headings below, or one may view [the list of all repositories](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
|
||||
-->
|
||||
|
||||
“树内”的云驱动通常需要在命令行中为 [kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kubelet](/docs/admin/kubelet/) 指定 `--cloud-provider` 和 `--cloud-config`。在 `--cloud-config` 中为每个供应商指定的文件的内容也同样需要写在下面。
|
||||
对于所有外部云驱动，请遵循独立云存储库的说明，或浏览[所有版本库清单](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
|
||||
“树内”的云驱动通常需要在命令行中为
|
||||
[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)、
|
||||
[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 和
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 指定
|
||||
`--cloud-provider` 和 `--cloud-config`。
|
||||
在 `--cloud-config` 中为每个供应商指定的文件内容的文档也可参见本文后文。
|
||||
对于所有外部云驱动，请遵循各自仓库的说明，或浏览
|
||||
[所有仓库清单](https://github.com/kubernetes?q=cloud-provider-&type=&language=)
|
||||
|
||||
<!--
|
||||
## AWS
|
||||
|
|
@ -79,8 +83,8 @@ be used when running Kubernetes on Amazon Web Services.
|
|||
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)
|
||||
-->
|
||||
|
||||
# AWS
|
||||
|
||||
本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。
|
||||
如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)
|
||||
|
||||
|
|
@ -100,7 +104,9 @@ to use specific features in AWS by configuring the annotations as shown below.
|
|||
-->
|
||||
### 负载均衡器
|
||||
|
||||
用户可以通过配置注解（annotations）来设置 [外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/)，以在 AWS 中使用特定功能，如下所示：
|
||||
用户可以通过配置注解（annotations）来设置
|
||||
[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，
|
||||
以在 AWS 中使用特定功能，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -125,7 +131,6 @@ spec:
|
|||
<!--
|
||||
Different settings can be applied to a load balancer service in AWS using _annotations_. The following describes the annotations supported on AWS ELBs:
|
||||
-->
|
||||
|
||||
可以使用 _注解_ 将不同的设置应用于 AWS 中的负载均衡器服务。下面描述了 AWS ELB 所支持的注解：
|
||||
|
||||
<!--
|
||||
|
|
@ -152,8 +157,15 @@ Different settings can be applied to a load balancer service in AWS using _annot
|
|||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`：用于指定访问日志的 S3 桶名称。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`：用于指定访问日志的 S3 桶前缀。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`：用于在服务中指定一个逗号分隔的键值对列表，它将作为附加标签被记录在 ELB 中。例如： `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。如果指定 `http`（默认）或 `https`，将创建一个终止连接和解析头的 HTTPS 监听器。 如果设置为 `ssl` 或 `tcp`，将会使用 “原生的” SSL 监听器。如果设置为 `http`且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的证书 ARN（Amazon Resource Name）。更多内容，请参考 [ELB 监听器配置](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。证书 ARN 是 IAM（身份和访问管理）或 CM（证书管理）类型的 ARN，例如 `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。
|
||||
如果指定 `http`（默认）或 `https`，将创建一个终止连接和解析头的 HTTPS 监听器。
|
||||
如果设置为 `ssl` 或 `tcp`，将会使用 “原生的” SSL 监听器。
|
||||
如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的
|
||||
证书 ARN（Amazon Resource Name）。更多内容请参考
|
||||
[ELB 监听器配置](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。
|
||||
证书 ARN 是 IAM（身份和访问管理）或 CM（证书管理）类型的 ARN，例如
|
||||
`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`：用于在服务中启用或禁用连接耗尽（connection draining）。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`：用于在服务中指定连接耗尽超时时间。
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`：用于在服务中指定空闲连接超时时间。
|
||||
|
|
@ -166,7 +178,6 @@ Different settings can be applied to a load balancer service in AWS using _annot
|
|||
<!--
|
||||
The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go)
|
||||
-->
|
||||
|
||||
AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/cloud-provider-aws/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。
|
||||
|
||||
## Azure
|
||||
|
|
@ -182,7 +193,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl
|
|||
The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Azure VM name.
|
||||
-->
|
||||
|
||||
### 节点名称
|
||||
|
||||
云驱动 Azure 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
|
||||
|
|
@ -202,7 +212,6 @@ If you wish to use the external cloud provider, its repository is [apache/clouds
|
|||
The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the CloudStack VM name.
|
||||
-->
|
||||
|
||||
### 节点名称
|
||||
|
||||
云驱动 CloudStack 使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
|
||||
|
|
@ -212,7 +221,6 @@ Note that the Kubernetes Node name must match the CloudStack VM name.
|
|||
<!--
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
|
||||
-->
|
||||
|
||||
如果希望使用此外部云驱动，其代码库位于 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
|
||||
|
||||
<!--
|
||||
|
|
@ -221,7 +229,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl
|
|||
The GCE cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the first segment of the Kubernetes Node name must match the GCE instance name (e.g. a Node named `kubernetes-node-2.c.my-proj.internal` must correspond to an instance named `kubernetes-node-2`).
|
||||
-->
|
||||
|
||||
### 节点名称
|
||||
|
||||
GCE 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
|
||||
|
|
@ -244,7 +251,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl
|
|||
The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object.
|
||||
Note that the instance name must be a valid Kubernetes Node name in order for the kubelet to successfully register its Node object.
|
||||
-->
|
||||
|
||||
### 节点名称
|
||||
|
||||
OpenStack 云驱动使用实例名（由 OpenStack 元数据确定）作为 Kubernetes 节点对象的名称。
|
||||
|
|
@ -286,12 +292,12 @@ a future release. As of the "Queens" release, OpenStack will no longer expose th
|
|||
Identity V2 API.
|
||||
§ Load Balancing V1 API support was removed in Kubernetes 1.9.
|
||||
-->
|
||||
† 块存储 V1 版本的 API 被弃用，从 Kubernetes 1.9 版本开始加入了块存储 V3 版本 API。
|
||||
|
||||
† Block Storage V1 版本的 API 被弃用，从 Kubernetes 1.9 版本开始加入了 Block Storage V3 版本 API。
|
||||
‡ 身份认证 V2 API 支持已被弃用，将在未来的版本中从供应商中移除。
|
||||
从 “Queens” 版本开始，OpenStack 将不再支持身份认证 V2 版本的 API。
|
||||
|
||||
‡ Identity V2 API 支持已被弃用，将在未来的版本中从供应商中移除。从 “Queens” 版本开始，OpenStack 将不再支持 Identity V2 版本的 API。
|
||||
|
||||
§ Kubernetes 1.9 中取消了对 V1 版本 Load Balancing API 的支持。
|
||||
§ Kubernetes 1.9 中取消了对 V1 版本负载均衡 API 的支持。
|
||||
|
||||
<!--
|
||||
Service discovery is achieved by listing the service catalog managed by
|
||||
|
|
@ -301,19 +307,19 @@ OpenStack services other than Keystone are not available and simply disclaim
|
|||
support for impacted features. Certain features are also enabled or disabled
|
||||
based on the list of extensions published by Neutron in the underlying cloud.
|
||||
-->
|
||||
|
||||
服务发现是通过使用供应商配置中提供的 `auth-url` 所列出 OpenStack 身份认证（Keystone）管理的服务目录来实现的。
|
||||
当除 Keystone 外的 OpenStack 服务不可用时，供应商将优雅地降低功能，并简单地放弃对受影响特性的支持。
|
||||
某些功能还可以根据 Neutron 在底层云中发布的扩展列表启用或禁用。
|
||||
|
||||
### cloud.conf
|
||||
|
||||
<!--
|
||||
Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is
|
||||
the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint.
|
||||
You can create a cloud.conf file by specifying the following details in it
|
||||
-->
|
||||
|
||||
Kubernetes 知道如何通过 cloud.conf 文件与 OpenStack 交互。该文件将为 Kubernetes 提供 OpenStack 验证端点的凭据和位置。
|
||||
Kubernetes 知道如何通过 cloud.conf 文件与 OpenStack 交互。
|
||||
该文件将为 Kubernetes 提供 OpenStack 验证端点的凭据和位置。
|
||||
用户可在创建 cloud.conf 文件时指定以下信息：
|
||||
|
||||
<!--
|
||||
|
|
@ -325,7 +331,8 @@ load balancer:
|
|||
-->
|
||||
#### 典型配置
|
||||
|
||||
下面是一个典型配置的例子，它涉及到最常设置的值。它将供应商指向 OpenStack 云的 Keystone 端点，提供如何使用它进行身份验证的细节，并配置负载均衡器:
|
||||
下面是一个典型配置的例子，它涉及到最常设置的值。它将供应商指向 OpenStack 云的 Keystone 端点，
|
||||
提供如何使用它进行身份验证的细节，并配置负载均衡器:
|
||||
|
||||
```yaml
|
||||
[Global]
|
||||
|
|
@ -344,7 +351,6 @@ These configuration options for the OpenStack provider pertain to its global
|
|||
configuration and should appear in the `[Global]` section of the `cloud.conf`
|
||||
file:
|
||||
-->
|
||||
|
||||
##### 全局配置
|
||||
|
||||
这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[global]` 部分:
|
||||
|
|
@ -377,22 +383,26 @@ file:
|
|||
* `ca-file` (Optional): Used to specify the path to your custom CA file.
|
||||
-->
|
||||
|
||||
* `auth-url` (必需): 用于认证的 keystone API 的 URL。在 OpenStack 控制面板中，这可以在“访问和安全（Access and Security）> API 访问（API Access）> 凭证（Credentials）”中找到。
|
||||
* `auth-url` (必需): 用于认证的 Keystone API 的 URL。在 OpenStack 控制面板中，
|
||||
这可以在“访问和安全（Access and Security）> API 访问（API Access）> 凭证（Credentials）”中找到。
|
||||
* `username` (必需): 指 keystone 中一个有效用户的用户名。
|
||||
* `password` (必需): 指 keystone 中一个有效用户的密码。
|
||||
* `tenant-id` (必需): 用于指定要创建资源的租户 ID。
|
||||
* `tenant-name` (可选): 用于指定要在其中创建资源的租户的名称。
|
||||
* `trust-id` (可选): 用于指定用于授权的信任的标识符。信任表示用户（委托人）将角色委托给另一个用户(受托人)的授权，并可选的允许受托人模仿委托人。可用的信任可以在 Keystone API 的 `/v3/OS-TRUST/trusts` 端点下找到。
|
||||
* `trust-id` (可选): 用于指定用于授权的信任的标识符。信任表示用户（委托人）
|
||||
将角色委托给另一个用户(受托人)的授权，并可选的允许受托人模仿委托人。
|
||||
可用的信任可以在 Keystone API 的 `/v3/OS-TRUST/trusts` 端点下找到。
|
||||
* `domain-id` (可选): 用于指定用户所属域的 ID。
|
||||
* `domain-name` (可选): 用于指定用户所属域的名称。
|
||||
* `region` (可选): 用于指定在多区域 OpenStack 云上运行时使用的区域标识符。区域是 OpenStack 部署的一般性划分。虽然区域没有严格的地理含义，但部署可以使用地理名称表示区域标识符，如 `us-east`。可用区域位于 Keystone API 的 `/v3/regions` 端点之下。
|
||||
* `region` (可选): 用于指定在多区域 OpenStack 云上运行时使用的区域标识符。
|
||||
区域是 OpenStack 部署的一般性划分。虽然区域没有严格的地理含义，但部署可以使用地理名称表示区域标识符，
|
||||
如 `us-east`。可用区域位于 Keystone API 的 `/v3/regions` 端点之下。
|
||||
* `ca-file` (可选): 用于指定自定义 CA 文件的路径。
|
||||
|
||||
<!--
|
||||
When using Keystone V3 - which changes tenant to project - the `tenant-id` value
|
||||
is automatically mapped to the project construct in the API.
|
||||
-->
|
||||
|
||||
当使用 Keystone V3 时(它将tenant更改为project)，`tenant-id` 值会自动映射到 API 中的项目。
|
||||
|
||||
<!--
|
||||
|
|
@ -401,7 +411,6 @@ These configuration options for the OpenStack provider pertain to the load
|
|||
balancer and should appear in the `[LoadBalancer]` section of the `cloud.conf`
|
||||
file:
|
||||
-->
|
||||
|
||||
#### 负载均衡器
|
||||
|
||||
这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[LoadBalancer]` 部分:
|
||||
|
|
@ -447,24 +456,34 @@ file:
|
|||
* `node-security-group` (Optional): ID of the security group to manage.
|
||||
-->
|
||||
|
||||
* `lb-version` (可选): 用于覆盖自动版本检测。有效值为 `v1` 或 `v2`。如果没有提供值，则自动选择底层 OpenStack 云所支持的最高版本。
|
||||
* `use-octavia` (可选): 用于确定是否查找和使用 Octavia LBaaS V2 服务目录端点。有效值是 `true` 或 `false`。
|
||||
如果指定了“true”，并且无法找到 Octaiva LBaaS V2 入口，则提供者将退回并尝试寻找一个 Neutron LBaaS V2 端点。默认值是 `false`。
|
||||
* `lb-version` (可选): 用于覆盖自动版本检测。有效值为 `v1` 或 `v2`。
|
||||
如果没有提供值，则自动选择底层 OpenStack 云所支持的最高版本。
|
||||
* `use-octavia` (可选): 用于确定是否查找和使用 Octavia LBaaS V2 服务目录端点。
|
||||
有效值是 `true` 或 `false`。
|
||||
如果指定了“true”，并且无法找到 Octaiva LBaaS V2 入口，则提供者将退回并尝试寻找一个
|
||||
Neutron LBaaS V2 端点。默认值是 `false`。
|
||||
* `subnet-id` (可选): 用于指定要在其上创建负载均衡器的子网的 ID。
|
||||
可以在 “Network > Networks” 上找到。
|
||||
单击相应的网络以获得其子网。
|
||||
可以在 “Network > Networks” 上找到。
|
||||
单击相应的网络以获得其子网。
|
||||
* `floating-network-id` (可选): 如果指定，将为负载均衡器创建一个浮动 IP。
|
||||
* `lb-method` (可选): 用于指定将负载分配到负载均衡器池成员的算法。值可以是 `ROUND_ROBIN`、`LEAST_CONNECTIONS` 或 `SOURCE_IP`。如果没有指定，默认行为是 `ROUND_ROBIN`。
|
||||
* `lb-provider` (可选): 用于指定负载均衡器的提供程序。如果没有指定，将使用在 Neutron 中配置的默认提供者服务。
|
||||
* `create-monitor` (可选): 指定是否为 Neutron 负载均衡器创建健康监视器。有效值是 `true` 和 `false`。
|
||||
默认为 `false`。当指定 `true` 时，还必须设置 `monitor-delay`、`monitor-timeout` 和 `monitor-max-retries`。
|
||||
* `lb-method` (可选): 用于指定将负载分配到负载均衡器池成员的算法。
|
||||
值可以是 `ROUND_ROBIN`、`LEAST_CONNECTIONS` 或 `SOURCE_IP`。
|
||||
如果没有指定，默认行为是 `ROUND_ROBIN`。
|
||||
* `lb-provider` (可选): 用于指定负载均衡器的提供程序。
|
||||
如果没有指定，将使用在 Neutron 中配置的默认提供者服务。
|
||||
* `create-monitor` (可选): 指定是否为 Neutron 负载均衡器创建健康监视器。
|
||||
有效值是 `true` 和 `false`。
|
||||
默认为 `false`。当指定 `true` 时，还必须设置 `monitor-delay`、`monitor-timeout` 和 `monitor-max-retries`。
|
||||
* `monitor-delay` (可选): 向负载均衡器的成员发送探测之间的时间间隔。
|
||||
确保您指定了一个有效的时间单位。
|
||||
有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。
|
||||
* `monitor-timeout` (可选): 在超时之前，监视器等待 ping 响应的最长时间。该值必须小于延迟值。确保您指定了一个有效的时间单位。有效时间单位为 `ns`、 `us` (或 `µs`)、`ms`、`s`、`m`、 `h`。
|
||||
确保您指定了一个有效的时间单位。
|
||||
有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。
|
||||
* `monitor-timeout` (可选): 在超时之前，监视器等待 ping 响应的最长时间。
|
||||
该值必须小于延迟值。确保您指定了一个有效的时间单位。
|
||||
有效时间单位为 `ns`、`us` (或 `µs`)、`ms`、`s`、`m`、`h`。
|
||||
* `monitor-max-retries` (可选): 在将负载均衡器成员的状态更改为非活动之前，允许 ping 失败的次数。
|
||||
必须是 1 到 10 之间的数字。
|
||||
* `manage-security-groups` (可选): 确定负载均衡器是否应自动管理安全组规则。有效值是 `true` 和 `false`。默认为 `false`。当指定 `true` 时，还必须提供 `node-security-group`。
|
||||
必须是 1 到 10 之间的数字。
|
||||
* `manage-security-groups` (可选): 确定负载均衡器是否应自动管理安全组规则。
|
||||
有效值是 `true` 和 `false`。默认为 `false`。当指定 `true` 时，还必须提供 `node-security-group`。
|
||||
* `node-security-group` (可选): 要管理的安全组的 ID。
|
||||
|
||||
<!--
|
||||
|
|
@ -472,7 +491,6 @@ file:
|
|||
These configuration options for the OpenStack provider pertain to block storage
|
||||
and should appear in the `[BlockStorage]` section of the `cloud.conf` file:
|
||||
-->
|
||||
|
||||
##### 块存储
|
||||
|
||||
这些配置选项属于 OpenStack 驱动的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[BlockStorage]` 部分：
|
||||
|
|
@ -498,12 +516,15 @@ and should appear in the `[BlockStorage]` section of the `cloud.conf` file:
|
|||
attached to the node, default is 256 for cinder.
|
||||
-->
|
||||
|
||||
* `bs-version` (可选): 指所使用的块存储 API 版本。其合法值为 `v1`、`v2`、`v3`和 `auto`。 `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。
|
||||
* `trust-device-path` (可选): 在大多数情况下，块设备名称由 Cinder 提供（例如：`/dev/vda`）不可信任。此布尔值切换此行为。将其设置为 `true` 将导致信任 Cinder 提供的块设备名称。默认值 `false` 会根据设备序列号和 `/dev/disk/by-id` 映射发现设备路径，推荐这种方法。
|
||||
* `bs-version` (可选): 指所使用的块存储 API 版本。其合法值为 `v1`、`v2`、`v3`和 `auto`。
|
||||
`auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。
|
||||
* `trust-device-path` (可选): 在大多数情况下，块设备名称由 Cinder 提供（例如：`/dev/vda`）不可信任。
|
||||
此布尔值切换此行为。将其设置为 `true` 将导致信任 Cinder 提供的块设备名称。
|
||||
默认值 `false` 会根据设备序列号和 `/dev/disk/by-id` 映射发现设备路径，推荐这种方法。
|
||||
* `ignore-volume-az` (可选): 用于在附加 Cinder 卷时影响可用区使用。
|
||||
当 Nova 和 Cinder 有不同的可用区域时，应该将其设置为 `true`。
|
||||
最常见的情况是，有许多 Nova 可用区，但只有一个 Cinder 可用区。
|
||||
默认值是 `false`，以保持在早期版本中使用的行为，但是将来可能会更改。
|
||||
当 Nova 和 Cinder 有不同的可用区域时，应该将其设置为 `true`。
|
||||
最常见的情况是，有许多 Nova 可用区，但只有一个 Cinder 可用区。
|
||||
默认值是 `false`，以保持在早期版本中使用的行为，但是将来可能会更改。
|
||||
* `node-volume-attach-limit` (可选): 可连接到节点的最大卷数，对于 Cinder 默认为 256。
|
||||
|
||||
<!--
|
||||
|
|
@ -519,17 +540,19 @@ returned on attempting volume detachment. To workaround this issue it is
|
|||
possible to force the use of Cinder API version 2 by adding this to the cloud
|
||||
provider configuration:
|
||||
-->
|
||||
如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（Endpoints），
|
||||
那么可能需要显式设置 `bs-version` 参数。
|
||||
基于路径的端点形如 `http://foo.bar/volume`，而基于端口的的端点形如 `http://foo.bar:xxx`。
|
||||
|
||||
如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（Endpoints），那么可能需要显式设置 `bs-version` 参数。 基于路径的端点形如 `http://foo.bar/volume`，而基于端口的的端点形如
|
||||
`http://foo.bar:xxx`。
|
||||
|
||||
在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，尝试卷卸载（Detachment）会返回 `BS API version autodetection failed.` 错误。为了解决这个问题，可以通过添加以下内容到云驱动配置中，来强制使用 Cinder API V2 版本。
|
||||
|
||||
在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，
|
||||
尝试卷卸载（Detachment）会返回 `BS API version autodetection failed.` 错误。
|
||||
为了解决这个问题，可以通过添加以下内容到云驱动配置中，来强制使用 Cinder API V2 版本。
|
||||
|
||||
```yaml
|
||||
[BlockStorage]
|
||||
bs-version=v2
|
||||
```
|
||||
|
||||
<!--
|
||||
##### Metadata
|
||||
These configuration options for the OpenStack provider pertain to metadata and
|
||||
|
|
@ -553,19 +576,22 @@ should appear in the `[Metadata]` section of the `cloud.conf` file:
|
|||
both configuration drive and metadata service though and only one or the other
|
||||
may be available which is why the default is to check both.
|
||||
-->
|
||||
|
||||
##### 元数据
|
||||
|
||||
这些配置选项属于 OpenStack 提供程序的全局配置，并且应该出现在 `cloud.conf` 文件中的 `[Metadata]` 部分：
|
||||
|
||||
* `search-order` (可选): 此配置键影响提供者检索与其运行的实例相关的元数据的方式。
|
||||
`configDrive，metadataService` 的默认值导致供应商首先从配置驱动器中检索与实例相关的元数据（如果可用的话），然后检索元数据服务。
|
||||
他们的替代值：
|
||||
`configDrive，metadataService` 的默认值导致供应商首先从配置驱动器中检索与实例相关的元数据（如果可用的话），
|
||||
然后检索元数据服务。
|
||||
他们的替代值：
|
||||
|
||||
* `configDrive` - 仅从配置驱动器检索实例元数据。
|
||||
* `metadataService` - 仅从元数据服务检索实例元数据。
|
||||
* `metadataService,configDrive` - 如果可用，首先从元数据服务检索实例元数据，然后从配置驱动器检索。
|
||||
|
||||
影响这种行为可能是可取的，因为配置驱动器上的元数据可能会随着时间的推移而变得陈旧，而元数据服务总是提供最新的数据视图。并不是所有的 OpenStack 云都同时提供配置驱动和元数据服务，可能只有一个或另一个可用，这就是为什么默认情况下要同时检查两个。
|
||||
影响这种行为可能是可取的，因为配置驱动器上的元数据可能会随着时间的推移而变得陈旧，
|
||||
而元数据服务总是提供最新的数据视图。并不是所有的 OpenStack 云都同时提供配置驱动和元数据服务，
|
||||
可能只有一个或另一个可用，这就是为什么默认情况下要同时检查两个。
|
||||
|
||||
<!--
|
||||
##### Route
|
||||
|
|
@ -578,20 +604,20 @@ Kubernetes network plugin and should appear in the `[Route]` section of the
|
|||
the `extraroutes` extension then use `router-id` to specify a router to add
|
||||
routes to. The router chosen must span the private networks containing your
|
||||
cluster nodes (typically there is only one node network, and this value should be
|
||||
the default router for the node network). This value is required to use [kubenet]
|
||||
the default router for the node network). This value is required to use
|
||||
[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)
|
||||
on OpenStack.
|
||||
|
||||
[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
|
||||
-->
|
||||
|
||||
##### 路由
|
||||
|
||||
这些配置选项属于 OpenStack 驱动为 Kubernetes 网络插件 [kubenet] 提供的设置，并且应该出现在 `cloud.conf` 文件中的 `[Route]` 部分:
|
||||
|
||||
* `router-id` (可选)：如果底层云的 Neutron 部署支持 `extraroutes` 扩展，则使用 `router-id` 指定要添加路由的路由器。选择的路由器必须跨越包含集群节点的私有网络（通常只有一个节点网络，这个值应该是节点网络的默认路由器）。在 OpenStack 上使用 [kubenet] 时需要这个值。
|
||||
|
||||
[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
|
||||
|
||||
* `router-id` (可选)：如果底层云的 Neutron 部署支持 `extraroutes` 扩展，
|
||||
则使用 `router-id` 指定要添加路由的路由器。
|
||||
选择的路由器必须跨越包含集群节点的私有网络（通常只有一个节点网络，这个值应该是节点网络的默认路由器）。
|
||||
在 OpenStack 上使用 [kubenet](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)
|
||||
时需要这个值。
|
||||
|
||||
|
||||
## OVirt
|
||||
|
|
@ -616,10 +642,13 @@ OVirt 云驱动使用节点的主机名（由 kubelet 确定，或者用 `--host
|
|||
The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address).
|
||||
-->
|
||||
|
||||
### 节点名称
|
||||
|
||||
Photon 云驱动使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
|
||||
注意，Kubernetes 节点名必须与 Photon VM名匹配（或者，如果在 `--cloud-config` 中将 `overrideIP` 设置为 `true`，则 Kubernetes 节点名必须与 Photon VM IP 地址匹配）。
|
||||
Photon 云驱动使用节点的主机名（由 kubelet 决定，或者用 `--hostname-override` 覆盖）
|
||||
作为 Kubernetes 节点对象的名称。
|
||||
注意，Kubernetes 节点名必须与 Photon VM名匹配（或者，如果在 `--cloud-config` 中将
|
||||
`overrideIP` 设置为 `true`，则 Kubernetes 节点名必须与 Photon VM IP 地址匹配）。
|
||||
|
||||
## VSphere
|
||||
|
||||
|
|
@ -645,45 +674,54 @@ The name of the Kubernetes Node object is the private IP address of the IBM Clou
|
|||
-->
|
||||
### 计算节点
|
||||
|
||||
通过使用 IBM Cloud Kubernetes Service 驱动，您可以在单个区域或跨区域的多个区（Region）中创建虚拟和物理（裸金属）节点的集群。
|
||||
通过使用 IBM Cloud Kubernetes Service 驱动，您可以在单个区域或跨区域的多个区（Region）
|
||||
中创建虚拟和物理（裸金属）节点的集群。
|
||||
有关更多信息，请参见[规划您的集群和工作节点设置](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters)。
|
||||
|
||||
Kubernetes 节点对象的名称是 IBM Cloud Kubernetes Services 工作节点实例的私有IP地址。
|
||||
|
||||
<!--
|
||||
### Networking
|
||||
|
||||
The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).
|
||||
|
||||
To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Planning to expose your apps with external networking](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
|
||||
-->
|
||||
### 网络
|
||||
|
||||
IBM Cloud Kubernetes Services 驱动提供 VLAN，用于提供高质量的网络性能和节点间的网络隔离。您可以设置自定义防火墙和 Calico 网络策略来为您的集群添加额外的安全层，或者通过 VPN 将您的集群连接到自有数据中心。有关更多信息，请参见[规划集群内和私有网络](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)。
|
||||
IBM Cloud Kubernetes Services 驱动提供 VLAN，用于提供高质量的网络性能和节点间的网络隔离。
|
||||
您可以设置自定义防火墙和 Calico 网络策略来为您的集群添加额外的安全层，或者通过 VPN
|
||||
将您的集群连接到自有数据中心。
|
||||
有关更多信息，请参见[规划集群内和私有网络](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)。
|
||||
|
||||
要向公众或集群内部公开应用程序，您可以利用 NodePort、LoadBalancer 或 Ingress 服务。您还可以使用注释自定义 Ingress 应用程序负载均衡器。有关更多信息，请参见[计划使用外部网络公开您的应用程序](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)。
|
||||
要向公众或集群内部公开应用程序，您可以利用 NodePort、LoadBalancer 或 Ingress 服务。
|
||||
您还可以使用注释自定义 Ingress 应用程序负载均衡器。
|
||||
有关更多信息，请参见[计划使用外部网络公开您的应用程序](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)。
|
||||
|
||||
<!--
|
||||
### Storage
|
||||
|
||||
The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
|
||||
-->
|
||||
|
||||
### 存储
|
||||
|
||||
IBM Cloud Kubernetes Services 驱动利用 Kubernetes 原生的持久卷，使用户能够将文件、块和云对象存储装载到他们的应用程序中。还可以使用 database-as-a-service 和第三方附加组件来持久存储数据。有关更多信息，请参见[规划高可用性持久存储](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)。
|
||||
IBM Cloud Kubernetes Services 驱动利用 Kubernetes 原生的持久卷，使用户能够将文件、块和云对象存储
|
||||
装载到他们的应用程序中。还可以使用 database-as-a-service 和第三方附加组件来持久存储数据。
|
||||
有关更多信息，请参见[规划高可用性持久存储](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)。
|
||||
|
||||
<!--
|
||||
## Baidu Cloud Container Engine
|
||||
|
||||
|
||||
### Node Name
|
||||
|
||||
The Baidu cloud provider uses the private IP address of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Baidu VM private IP.
|
||||
-->
|
||||
|
||||
## 百度云容器引擎
|
||||
|
||||
### 节点名称
|
||||
|
||||
Baidu 云驱动使用节点的私有 IP 地址（由 kubelet 确定，或者用 `--hostname-override` 覆盖）作为 Kubernetes 节点对象的名称。
|
||||
Baidu 云驱动使用节点的私有 IP 地址（由 kubelet 确定，或者用 `--hostname-override` 覆盖）
|
||||
作为 Kubernetes 节点对象的名称。
|
||||
注意 Kubernetes 节点名必须匹配百度 VM 的私有 IP。
|
||||
|
|
|
|||
|
|
@ -1,25 +1,33 @@
|
|||
---
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: 日志架构
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: Logging Architecture
|
||||
content_type: concept
|
||||
weight: 60
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
|
||||
-->
|
||||
应用和系统日志可以让您了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。
|
||||
应用和系统日志可以让你了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。
|
||||
大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。
|
||||
针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。
|
||||
|
||||
<!--
|
||||
However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
|
||||
-->
|
||||
但是，由容器引擎或 runtime 提供的原生功能通常不足以满足完整的日志记录方案。例如，如果发生容器崩溃、pod 被逐出或节点宕机等情况，您仍然想访问到应用日志。因此，日志应该具有独立的存储和生命周期，与节点、pod 或容器的生命周期相独立。这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。Kubernetes 没有为日志数据提供原生存储方案，但是您可以集成许多现有的日志解决方案到 Kubernetes 集群中。
|
||||
|
||||
|
||||
但是，由容器引擎或运行时提供的原生功能通常不足以满足完整的日志记录方案。
|
||||
例如，如果发生容器崩溃、Pod 被逐出或节点宕机等情况，你仍然想访问到应用日志。
|
||||
因此，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。
|
||||
这个概念叫 _集群级的日志_ 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。
|
||||
Kubernetes 没有为日志数据提供原生存储方案，但是你可以集成许多现有的日志解决方案到 Kubernetes 集群中。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -29,7 +37,8 @@ a logging backend is present inside or outside of your cluster. If you're
|
|||
not interested in having cluster-level logging, you might still find
|
||||
the description of how logs are stored and handled on the node to be useful.
|
||||
-->
|
||||
集群级日志架构假定在集群内部或者外部有一个日志后台。如果您对集群级日志不感兴趣，您仍会发现关于如何在节点上存储和处理日志的描述对您是有用的。
|
||||
集群级日志架构假定在集群内部或者外部有一个日志后台。
|
||||
如果你对集群级日志不感兴趣，你仍会发现关于如何在节点上存储和处理日志的描述对你是有用的。
|
||||
|
||||
<!--
|
||||
## Basic logging in Kubernetes
|
||||
|
|
@ -41,15 +50,16 @@ a container that writes some text to standard output once per second.
|
|||
-->
|
||||
## Kubernetes 中的基本日志记录
|
||||
|
||||
本节，您会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。
|
||||
这里通过一个特定的 [pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器，并令该容器每秒钟向标准输出写入数据。
|
||||
本节，你会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。
|
||||
这里通过一个特定的 [Pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器，
|
||||
并令该容器每秒钟向标准输出写入数据。
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
To run this pod, use the following command:
|
||||
-->
|
||||
用下面的命令运行 pod：
|
||||
用下面的命令运行 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
|
|
@ -72,6 +82,7 @@ To fetch the logs, use the `kubectl logs` command, as follows:
|
|||
```shell
|
||||
kubectl logs counter
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is:
|
||||
-->
|
||||
|
|
@ -87,8 +98,8 @@ The output is:
|
|||
<!--
|
||||
You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
-->
|
||||
一旦发生容器崩溃，您可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。
|
||||
如果 pod 中有多个容器，您应该向该命令附加一个容器名以访问对应容器的日志。
|
||||
一旦发生容器崩溃，你可以使用命令 `kubectl logs` 和参数 `--previous` 检索之前的容器日志。
|
||||
如果 pod 中有多个容器，你应该向该命令附加一个容器名以访问对应容器的日志。
|
||||
详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。
|
||||
|
||||
<!--
|
||||
|
|
@ -104,23 +115,23 @@ You can use `kubectl logs` to retrieve logs from a previous instantiation of a c
|
|||
Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
|
||||
-->
|
||||
容器化应用写入 `stdout` 和 `stderr` 的任何数据，都会被容器引擎捕获并被重定向到某个位置。
|
||||
例如，Docker 容器引擎将这两个输出流重定向到某个 [日志驱动](https://docs.docker.com/engine/admin/logging/overview) ，
|
||||
该日志驱动在 Kubernetes 中配置为以 json 格式写入文件。
|
||||
例如，Docker 容器引擎将这两个输出流重定向到某个
|
||||
[日志驱动](https://docs.docker.com/engine/admin/logging/overview) ，
|
||||
该日志驱动在 Kubernetes 中配置为以 JSON 格式写入文件。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
Docker json 日志驱动将日志的每一行当作一条独立的消息。该日志驱动不直接支持多行消息。您需要在日志代理级别或更高级别处理多行消息。
|
||||
Docker JSON 日志驱动将日志的每一行当作一条独立的消息。
|
||||
该日志驱动不直接支持多行消息。你需要在日志代理级别或更高级别处理多行消息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
|
||||
-->
|
||||
默认情况下，如果容器重启，kubelet 会保留被终止的容器日志。
|
||||
如果 pod 在工作节点被驱逐，该 pod 中所有的容器也会被驱逐，包括容器日志。
|
||||
如果 Pod 在工作节点被驱逐，该 Pod 中所有的容器也会被驱逐，包括容器日志。
|
||||
|
||||
<!--
|
||||
An important consideration in node-level logging is implementing log rotation,
|
||||
|
|
@ -137,8 +148,9 @@ default rotation is configured to take place when log file exceeds 10MB.
|
|||
-->
|
||||
节点级日志记录中，需要重点考虑实现日志的轮转，以此来保证日志不会消耗节点上所有的可用空间。
|
||||
Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个解决问题的方案。
|
||||
例如，在 Kubernetes 集群中，用 `kube-up.sh` 部署一个每小时运行的工具 [`logrotate`](https://linux.die.net/man/8/logrotate)。
|
||||
您也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 `log-opt` 选项。
|
||||
例如，在 Kubernetes 集群中，用 `kube-up.sh` 部署一个每小时运行的工具
|
||||
[`logrotate`](https://linux.die.net/man/8/logrotate)。
|
||||
你也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 `log-opt` 选项。
|
||||
在 `kube-up.sh` 脚本中，使用后一种方式来处理 GCP 上的 COS 镜像，而使用前一种方式来处理其他环境。
|
||||
这两种方式，默认日志超过 10MB 大小时都会触发日志轮转。
|
||||
|
||||
|
|
@ -146,8 +158,9 @@ Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个
|
|||
As an example, you can find detailed information about how `kube-up.sh` sets
|
||||
up logging for COS image on GCP in the corresponding [script][cosConfigureHelper].
|
||||
-->
|
||||
例如，您可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息，
|
||||
相应的脚本在 [这里][cosConfigureHelper]。
|
||||
例如，你可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息，
|
||||
相应的脚本在
|
||||
[这里](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
|
||||
|
||||
<!--
|
||||
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
|
||||
|
|
@ -157,7 +170,6 @@ reads directly from the log file, returning the contents in the response.
|
|||
当运行 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) 时，
|
||||
节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Currently, if some external system has performed the rotation,
|
||||
only the contents of the latest log file will be available through
|
||||
|
|
@ -165,12 +177,12 @@ only the contents of the latest log file will be available through
|
|||
the rotation and there are two files, one 10MB in size and one empty,
|
||||
`kubectl logs` will return an empty response.
|
||||
-->
|
||||
{{< note >}}
|
||||
当前，如果有其他系统机制执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。
|
||||
比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。
|
||||
比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，
|
||||
一个为空，所以 `kubectl logs` 将返回空。
|
||||
{{< /note >}}
|
||||
|
||||
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
|
||||
|
||||
<!--
|
||||
### System component logs
|
||||
|
||||
|
|
@ -198,8 +210,9 @@ components in the [development docs on logging](https://github.com/kubernetes/co
|
|||
-->
|
||||
在使用 systemd 机制的服务器上，kubelet 和容器 runtime 写入日志到 journald。
|
||||
如果没有 systemd，他们写入日志到 `/var/log` 目录的 `.log` 文件。
|
||||
容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。他们使用 [klog][klog] 日志库。
|
||||
您可以在[日志开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)找到这些组件的日志告警级别协议。
|
||||
容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。他们使用
|
||||
[klog](https://github.com/kubernetes/klog) 日志库。
|
||||
你可以在[日志开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)找到这些组件的日志告警级别协议。
|
||||
|
||||
<!--
|
||||
Similarly to the container logs, system component logs in the `/var/log`
|
||||
|
|
@ -208,23 +221,21 @@ the `kube-up.sh` script, those logs are configured to be rotated by
|
|||
the `logrotate` tool daily or once the size exceeds 100MB.
|
||||
-->
|
||||
和容器日志类似，`/var/log` 目录中的系统组件日志也应该被轮转。
|
||||
通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中，日志被工具 `logrotate` 执行每日轮转，或者日志大小超过 100MB 时触发轮转。
|
||||
|
||||
[klog]: https://github.com/kubernetes/klog
|
||||
通过脚本 `kube-up.sh` 启动的 Kubernetes 集群中，日志被工具 `logrotate` 执行每日轮转，
|
||||
或者日志大小超过 100MB 时触发轮转。
|
||||
|
||||
<!--
|
||||
## Cluster-level logging architectures
|
||||
-->
|
||||
## 集群级日志架构
|
||||
|
||||
<!--
|
||||
While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options:
|
||||
|
||||
* Use a node-level logging agent that runs on every node.
|
||||
* Include a dedicated sidecar container for logging in an application pod.
|
||||
* Push logs directly to a backend from within an application.
|
||||
-->
|
||||
虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但您可以考虑几种常见的方法。以下是一些选项：
|
||||
## 集群级日志架构
|
||||
|
||||
虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但你可以考虑几种常见的方法。以下是一些选项：
|
||||
|
||||
* 使用在每个节点上运行的节点级日志记录代理。
|
||||
* 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。
|
||||
|
|
@ -242,35 +253,41 @@ While Kubernetes does not provide a native solution for cluster-level logging, t
|
|||
<!--
|
||||
You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node.
|
||||
-->
|
||||
您可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现群集级日志记录。日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。
|
||||
你可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现群集级日志记录。
|
||||
日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。
|
||||
通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。
|
||||
|
||||
<!--
|
||||
Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged.
|
||||
-->
|
||||
由于日志记录代理必须在每个节点上运行，它可以用 DaemonSet 副本，Pod 或 本机进程来实现。然而，后两种方法被弃用并且非常不别推荐。
|
||||
由于日志记录代理必须在每个节点上运行，它可以用 DaemonSet 副本，Pod 或 本机进程来实现。
|
||||
然而，后两种方法被弃用并且非常不别推荐。
|
||||
|
||||
<!--
|
||||
Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_.
|
||||
-->
|
||||
对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式，因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。
|
||||
对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式，
|
||||
因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。
|
||||
但是，节点级的日志 _仅适用于应用程序的标准输出和标准错误输出_。
|
||||
|
||||
<!--
|
||||
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
|
||||
-->
|
||||
Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
|
||||
[Stackdriver 日志](/docs/user-guide/logging/stackdriver) 适用于 Google Cloud Platform，和 [Elasticsearch](/docs/user-guide/logging/elasticsearch)。
|
||||
您可以在专门的文档中找到更多的信息和说明。两者都使用 [fluentd](http://www.fluentd.org/) 与自定义配置作为节点上的代理。
|
||||
[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
适用于 Google Cloud Platform，和
|
||||
[Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。
|
||||
你可以在专门的文档中找到更多的信息和说明。
|
||||
两者都使用 [fluentd](https://www.fluentd.org/) 与自定义配置作为节点上的代理。
|
||||
|
||||
<!--
|
||||
### Using a sidecar container with the logging agent
|
||||
|
||||
You can use a sidecar container in one of the following ways:
|
||||
-->
|
||||
### 使用 sidecar 容器和日志代理
|
||||
|
||||
<!--
|
||||
You can use a sidecar container in one of the following ways:
|
||||
-->
|
||||
您可以通过以下方式之一使用 sidecar 容器：
|
||||
你可以通过以下方式之一使用 sidecar 容器：
|
||||
|
||||
<!--
|
||||
* The sidecar container streams application logs to its own `stdout`.
|
||||
|
|
@ -281,10 +298,7 @@ You can use a sidecar container in one of the following ways:
|
|||
|
||||
<!--
|
||||
#### Streaming sidecar container
|
||||
-->
|
||||
#### 传输数据流的 sidecar 容器
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
By having your sidecar containers stream to their own `stdout` and `stderr`
|
||||
|
|
@ -293,8 +307,14 @@ already run on each node. The sidecar containers read logs from a file, a socket
|
|||
or the journald. Each individual sidecar container prints log to its own `stdout`
|
||||
or `stderr` stream.
|
||||
-->
|
||||
利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式，您就可以利用每个节点上的 kubelet 和日志代理来处理日志。
|
||||
sidecar 容器从文件，socket 或 journald 读取日志。每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。
|
||||
#### 传输数据流的 sidecar 容器
|
||||
|
||||
|
||||
|
||||
利用 sidecar 容器向自己的 `stdout` 和 `stderr` 传输流的方式，
|
||||
你就可以利用每个节点上的 kubelet 和日志代理来处理日志。
|
||||
sidecar 容器从文件、套接字或 journald 读取日志。
|
||||
每个 sidecar 容器打印其自己的 `stdout` 和 `stderr` 流。
|
||||
|
||||
<!--
|
||||
This approach allows you to separate several log streams from different
|
||||
|
|
@ -304,7 +324,8 @@ is minimal, so it's hardly a significant overhead. Additionally, because
|
|||
`stdout` and `stderr` are handled by the kubelet, you can use built-in tools
|
||||
like `kubectl logs`.
|
||||
-->
|
||||
这种方法允许您将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 `stdout` 或 `stderr` 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。
|
||||
这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入
|
||||
`stdout` 或 `stderr` 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。
|
||||
另外，因为 `stdout`、`stderr` 由 kubelet 处理，你可以使用内置的工具 `kubectl logs`。
|
||||
|
||||
<!--
|
||||
|
|
@ -323,14 +344,14 @@ the container. Instead, you could introduce two sidecar containers. Each sidecar
|
|||
container could tail a particular log file from a shared volume and then redirect
|
||||
the logs to its own `stdout` stream.
|
||||
-->
|
||||
在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使您试图重定向它们到容器的 `stdout` 流。
|
||||
取而代之的是，您可以引入两个 sidecar 容器。
|
||||
在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使你试图重定向它们到容器的 `stdout` 流。
|
||||
取而代之的是，你可以引入两个 sidecar 容器。
|
||||
每一个 sidecar 容器可以从共享卷跟踪特定的日志文件，并重定向文件内容到各自的 `stdout` 流。
|
||||
|
||||
<!--
|
||||
Here's a configuration file for a pod that has two sidecar containers:
|
||||
-->
|
||||
这是运行两个 sidecar 容器的 pod 文件。
|
||||
这是运行两个 sidecar 容器的 Pod 文件。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
|
|
@ -338,7 +359,7 @@ Here's a configuration file for a pod that has two sidecar containers:
|
|||
Now when you run this pod, you can access each log stream separately by
|
||||
running the following commands:
|
||||
-->
|
||||
现在当您运行这个 pod 时，您可以分别地访问每一个日志流，运行如下命令：
|
||||
现在当你运行这个 Pod 时，你可以分别地访问每一个日志流，运行如下命令：
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-1
|
||||
|
|
@ -365,7 +386,7 @@ The node-level agent installed in your cluster picks up those log streams
|
|||
automatically without any further configuration. If you like, you can configure
|
||||
the agent to parse log lines depending on the source container.
|
||||
-->
|
||||
集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果您愿意，您可以配置代理程序来解析源容器的日志行。
|
||||
集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果你愿意，你可以配置代理程序来解析源容器的日志行。
|
||||
|
||||
<!--
|
||||
Note, that despite low CPU and memory usage (order of couple of millicores
|
||||
|
|
@ -377,7 +398,7 @@ container approach.
|
|||
-->
|
||||
注意，尽管 CPU 和内存使用率都很低（以多个 cpu millicores 指标排序或者按内存的兆字节排序），
|
||||
向文件写日志然后输出到 `stdout` 流仍然会成倍地增加磁盘使用率。
|
||||
如果您的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，而不是使用流式的 sidecar 容器方式。
|
||||
如果你的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，而不是使用流式的 sidecar 容器方式。
|
||||
|
||||
<!--
|
||||
Sidecar containers can also be used to rotate log files that cannot be
|
||||
|
|
@ -404,7 +425,8 @@ If the node-level logging agent is not flexible enough for your situation, you
|
|||
can create a sidecar container with a separate logging agent that you have
|
||||
configured specifically to run with your application.
|
||||
-->
|
||||
如果节点级日志记录代理程序对于你的场景来说不够灵活，您可以创建一个带有单独日志记录代理程序的 sidecar 容器，将代理程序专门配置为与您的应用程序一起运行。
|
||||
如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个带有单独日志记录代理程序的
|
||||
sidecar 容器，将代理程序专门配置为与你的应用程序一起运行。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
|
|
@ -415,7 +437,8 @@ by the kubelet.
|
|||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
在 sidecar 容器中使用日志代理会导致严重的资源损耗。此外，您不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。
|
||||
在 sidecar 容器中使用日志代理会导致严重的资源损耗。
|
||||
此外，你不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -424,9 +447,11 @@ which uses fluentd as a logging agent. Here are two configuration files that
|
|||
you can use to implement this approach. The first file contains
|
||||
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
|
||||
-->
|
||||
例如，您可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，它使用fluentd作为日志记录代理。
|
||||
例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)，
|
||||
它使用 fluentd 作为日志记录代理。
|
||||
以下是两个可用于实现此方法的配置文件。
|
||||
第一个文件包含配置 fluentd 的[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
第一个文件包含配置 fluentd 的
|
||||
[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
|
|
@ -438,28 +463,29 @@ information about configuring fluentd, see the
|
|||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
配置fluentd超出了本文的范围。要知道更多的关于如何配置fluentd，请参考[fluentd 官方文档](http://docs.fluentd.org/).
|
||||
配置 fluentd 超出了本文的范围。要进一步了解如何配置 fluentd，
|
||||
请参考 [fluentd 官方文档](https://docs.fluentd.org/).
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The second file describes a pod that has a sidecar container running fluentd.
|
||||
The pod mounts a volume where fluentd can pick up its configuration data.
|
||||
-->
|
||||
第二个文件描述了运行 fluentd sidecar 容器的 pod 。flutend 通过 pod 的挂载卷获取它的配置数据。
|
||||
第二个文件描述了运行 fluentd sidecar 容器的 Pod 。flutend 通过 Pod 的挂载卷获取它的配置数据。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
|
||||
<!--
|
||||
After some time you can find log messages in the Stackdriver interface.
|
||||
-->
|
||||
一段时间后，您可以在 Stackdriver 界面看到日志消息。
|
||||
一段时间后，你可以在 Stackdriver 界面看到日志消息。
|
||||
|
||||
<!--
|
||||
Remember, that this is just an example and you can actually replace fluentd
|
||||
with any logging agent, reading from any source inside an application
|
||||
container.
|
||||
-->
|
||||
记住，这只是一个例子，事实上您可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。
|
||||
记住，这只是一个例子，事实上你可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。
|
||||
|
||||
<!--
|
||||
### Exposing logs directly from the application
|
||||
|
|
@ -476,6 +502,7 @@ You can implement cluster-level logging by exposing or pushing logs directly fro
|
|||
every application; however, the implementation for such a logging mechanism
|
||||
is outside the scope of Kubernetes.
|
||||
-->
|
||||
通过暴露或推送每个应用的日志，您可以实现集群级日志记录；然而，这种日志记录机制的实现已超出 Kubernetes 的范围。
|
||||
通过暴露或推送每个应用的日志，你可以实现集群级日志记录；
|
||||
然而，这种日志记录机制的实现已超出 Kubernetes 的范围。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
title: Kubernetes 控制面的指标
|
||||
content_type: concept
|
||||
weight: 60
|
||||
aliases:
|
||||
- controller-metrics.md
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -11,12 +13,11 @@ System component metrics can give a better look into what is happening inside th
|
|||
|
||||
Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
|
||||
-->
|
||||
|
||||
系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。
|
||||
|
||||
Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) 格式发出的，而且是易于阅读的。
|
||||
|
||||
|
||||
Kubernetes 控制面板中的指标是以
|
||||
[prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/)
|
||||
格式发出的，而且是易于阅读的。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -24,15 +25,14 @@ Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/doc
|
|||
## Metrics in Kubernetes
|
||||
In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
|
||||
-->
|
||||
|
||||
## Kubernetes 的指标
|
||||
|
||||
在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用，对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
|
||||
在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用。
|
||||
对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。
|
||||
|
||||
<!--
|
||||
Examples of those components:
|
||||
-->
|
||||
|
||||
举例下面这些组件：
|
||||
|
||||
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
|
||||
|
|
@ -50,12 +50,16 @@ Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes
|
|||
If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
|
||||
For example:
|
||||
-->
|
||||
在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/)
|
||||
或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。
|
||||
|
||||
在生产环境中，你可能需要配置 [Prometheus Server](https://prometheus.io/) 或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。
|
||||
请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在
|
||||
`/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。
|
||||
这些指标的生命周期并不相同。
|
||||
|
||||
请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在 `/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。这些指标的生命周期并不相同。
|
||||
|
||||
如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ，那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，才有权限访问 `/metrics` 。
|
||||
如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}，
|
||||
那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，
|
||||
才有权限访问 `/metrics` 。
|
||||
|
||||
举例：
|
||||
|
||||
|
|
@ -79,7 +83,6 @@ Alpha metrics have no stability guarantees; as such they can be modified or dele
|
|||
|
||||
Stable metrics can be guaranteed to not change; Specifically, stability means:
|
||||
-->
|
||||
|
||||
## 指标的生命周期
|
||||
|
||||
内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除
|
||||
|
|
@ -101,8 +104,8 @@ Deprecated metric signal that the metric will eventually be deleted; to find whi
|
|||
|
||||
Before deprecation:
|
||||
-->
|
||||
|
||||
弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，注释中包括该指标从哪个 kubernetes 版本被弃用。
|
||||
弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，
|
||||
注释中包括该指标从哪个 kubernetes 版本被弃用。
|
||||
|
||||
指标弃用前：
|
||||
|
||||
|
|
@ -112,10 +115,7 @@ Before deprecation:
|
|||
some_counter 0
|
||||
```
|
||||
|
||||
<!--
|
||||
After deprecation:
|
||||
-->
|
||||
|
||||
<!-- After deprecation: -->
|
||||
指标弃用后：
|
||||
|
||||
```
|
||||
|
|
@ -129,8 +129,8 @@ Once a metric is hidden then by default the metrics is not published for scrapin
|
|||
|
||||
Once a metric is deleted, the metric is not published. You cannot change this using an override.
|
||||
-->
|
||||
|
||||
一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
|
||||
一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。
|
||||
如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。
|
||||
|
||||
一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。
|
||||
|
||||
|
|
@ -145,14 +145,17 @@ The flag can only take the previous minor version as it's value. All metrics hid
|
|||
|
||||
Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
|
||||
-->
|
||||
|
||||
## 显示隐藏指标
|
||||
|
||||
综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
|
||||
综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。
|
||||
当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。
|
||||
|
||||
`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
|
||||
`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。
|
||||
这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，
|
||||
尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。
|
||||
|
||||
这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
|
||||
这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，
|
||||
那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。
|
||||
|
||||
以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论：
|
||||
|
||||
|
|
@ -168,7 +171,9 @@ If you're upgrading from release `1.12` to `1.13`, but still depend on a metric
|
|||
* 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出.
|
||||
* 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了.
|
||||
|
||||
如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12` ，但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
|
||||
如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，
|
||||
你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12`，
|
||||
但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。
|
||||
|
||||
<!--
|
||||
## Component metrics
|
||||
|
|
@ -185,7 +190,6 @@ These metrics can be used to monitor health of persistent volume operations.
|
|||
|
||||
For example, for GCE these metrics are called:
|
||||
-->
|
||||
|
||||
## 组件指标
|
||||
|
||||
### kube-controller-manager 指标
|
||||
|
|
@ -205,11 +209,8 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
|||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
|
||||
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
|
||||
|
|
@ -218,6 +219,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
|||
|
||||
* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
|
||||
* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
|
||||
* 了解有关 [Kubernetes 指标弃用策略](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
* 了解有关 [Kubernetes 指标弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue