Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: 集群管理
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
关于创建和管理 Kubernetes 集群的底层细节。
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Cluster Administration
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
Lower-level detail relevant to creating or administering a Kubernetes cluster.
|
||||
no_list: true
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
-->
|
||||
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。
|
||||
我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
## Planning a cluster
|
||||
|
||||
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
|
||||
|
||||
Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
|
||||
Before choosing a guide, here are some considerations:
|
||||
-->
|
||||
## 规划集群 {#planning-a-cluster}
|
||||
|
||||
查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes
|
||||
集群的示例。本文所列的文章称为*发行版* 。
|
||||
|
||||
{{< note >}}
|
||||
并非所有发行版都是被积极维护的。
|
||||
请选择使用最近 Kubernetes 版本测试过的发行版。
|
||||
{{< /note >}}
|
||||
|
||||
在选择一个指南前，有一些因素需要考虑：
|
||||
|
||||
<!--
|
||||
- Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
|
||||
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
|
||||
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
|
||||
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
|
||||
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
|
||||
- Do you **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/concepts/overview/components/) needed to run a cluster.
|
||||
-->
|
||||
- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？
|
||||
请选择最适合你需求的发行版。
|
||||
- 你正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)
|
||||
这样的**被托管的 Kubernetes 集群**, 还是**管理你自己的集群**？
|
||||
- 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。
|
||||
作为代替，你可以建立多个集群。
|
||||
- **如果你在本地配置 Kubernetes**，需要考虑哪种
|
||||
[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。
|
||||
- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？
|
||||
- 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？
|
||||
如果是后者，请选择一个处于开发状态的发行版。
|
||||
某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。
|
||||
|
||||
<!--
|
||||
## Managing a cluster
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
-->
|
||||
## 管理集群 {#managing-a-cluster}
|
||||
|
||||
* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。
|
||||
|
||||
* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。
|
||||
|
||||
<!--
|
||||
## Securing a cluster
|
||||
|
||||
* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.
|
||||
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
|
||||
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
-->
|
||||
## 保护集群 {#securing-a-cluster}
|
||||
|
||||
* [生成证书](/zh/docs/tasks/administer-cluster/certificates/)
|
||||
节描述了使用不同的工具链生成证书的步骤。
|
||||
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)
|
||||
描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
|
||||
描述了如何为用户和 service accounts 建立权限许可。
|
||||
* [身份认证](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
|
||||
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)
|
||||
与身份认证不同，用于控制如何处理 HTTP 请求。
|
||||
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers)
|
||||
阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
|
||||
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)
|
||||
描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
|
||||
* [审计](/zh/docs/tasks/debug/debug-cluster/audit/)
|
||||
描述了如何与 Kubernetes 的审计日志交互。
|
||||
|
||||
<!--
|
||||
### Securing the kubelet
|
||||
|
||||
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
-->
|
||||
### 保护 kubelet {#securing-the-kubelet}
|
||||
|
||||
* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
|
||||
<!--
|
||||
## Optional Cluster Services
|
||||
|
||||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
-->
|
||||
## 可选集群服务 {#optional-cluster-services}
|
||||
|
||||
* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)
|
||||
描述了如何将一个 DNS 名解析到一个 Kubernetes service。
|
||||
* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)
|
||||
阐述了 Kubernetes 的日志如何工作以及怎样实现。
|
||||
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: 安装扩展（Addons）
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
Add-ons extend the functionality of Kubernetes.
|
||||
|
||||
This page lists some of the available add-ons and links to their respective installation instructions.
|
||||
|
||||
Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
|
||||
-->
|
||||
Add-ons 扩展了 Kubernetes 的功能。
|
||||
|
||||
本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。
|
||||
|
||||
每个 Add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Networking and Network Policy
|
||||
|
||||
* [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI.
|
||||
* [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane.
|
||||
* [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) is a secure L3 networking and network policy provider.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
|
||||
* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
|
||||
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
|
||||
* Multus is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
|
||||
* **Romana** 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/kubernetes/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 提供集成的容器网络和安全网络。
|
||||
* [Antrea](https://antrea.io/) 在第 3/4 层执行操作，为 Kubernetes
|
||||
提供网络连接和安全服务。Antrea 利用 Open vSwitch 作为网络的数据面。
|
||||
* [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](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络
|
||||
（使用 BGP 的本机 L3、使用 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。
|
||||
Contiv 项目完全[开源](https://github.com/contiv)。
|
||||
[安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 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/flannel-io/flannel#deploying-flannel-manually)
|
||||
是一个可以用于 Kubernetes 的 overlay 网络提供者。
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) 是为 kubernetes 提供复合网络解决方案的网络组件。
|
||||
* Multus 是一个多插件，可在 Kubernetes 中提供多种网络支持，
|
||||
以支持所有 CNI 插件（例如 Calico，Cilium，Contiv，Flannel），
|
||||
而且包含了在 Kubernetes 中基于 SRIOV、DPDK、OVS-DPDK 和 VPP 的工作负载。
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) 是一个 Kubernetes 网络驱动，
|
||||
基于 [OVN（Open Virtual Network）](https://github.com/ovn-org/ovn/)实现，是从 Open vSwitch (OVS)
|
||||
项目衍生出来的虚拟网络实现。
|
||||
OVN-Kubernetes 为 Kubernetes 提供基于覆盖网络的网络实现，包括一个基于 OVS 实现的负载均衡器
|
||||
和网络策略。
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是一个基于 OVN 的 CNI
|
||||
控制器插件，提供基于云原生的服务功能链条（Service Function Chaining，SFC）、多种 OVN 覆盖
|
||||
网络、动态子网创建、动态虚拟网络创建、VLAN 驱动网络、直接驱动网络，并且可以
|
||||
驳接其他的多网络插件，适用于基于边缘的、多集群联网的云原生工作负载。
|
||||
* [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 是一个 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/kubernetes/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 服务。
|
||||
|
||||
<!--
|
||||
## Visualization & Control
|
||||
|
||||
* [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) 是一个图形化工具，
|
||||
用于查看你的容器、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.
|
||||
* The
|
||||
[node problem detector](https://github.com/kubernetes/node-problem-detector)
|
||||
runs on Linux nodes and reports system issues as either
|
||||
[Events](/docs/reference/kubernetes-api/cluster-resources/event-v1/) or
|
||||
[Node conditions](/docs/concepts/architecture/nodes/#condition).
|
||||
-->
|
||||
## 基础设施
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes
|
||||
运行虚拟机的 add-ons。通常运行在裸机集群上。
|
||||
* [节点问题检测器](https://github.com/kubernetes/node-problem-detector) 在 Linux 节点上运行，
|
||||
并将系统问题报告为[事件](/docs/reference/kubernetes-api/cluster-resources/event-v1/)
|
||||
或[节点状况](/zh/docs/concepts/architecture/nodes/#condition)。
|
||||
|
||||
<!--
|
||||
## Legacy Add-ons
|
||||
|
||||
There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory.
|
||||
|
||||
Well-maintained ones should be linked to here. PRs welcome!
|
||||
-->
|
||||
## 遗留 Add-ons
|
||||
|
||||
还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。
|
||||
|
||||
维护完善的 add-ons 应该被链接到这里。欢迎提出 PRs！
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: 证书
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
title: Certificates
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
To learn how to generate certificates for your cluster, see [Certificates](/docs/tasks/administer-cluster/certificates/).
|
||||
-->
|
||||
要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,521 @@
|
||||
---
|
||||
title: 日志架构
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: Logging Architecture
|
||||
content_type: concept
|
||||
weight: 60
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to 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, you may want to access your application's logs if a container crashes; a pod gets evicted; or a node dies,
|
||||
In a cluster, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_.
|
||||
-->
|
||||
但是，由容器引擎或运行时提供的原生功能通常不足以构成完整的日志记录方案。
|
||||
例如，如果发生容器崩溃、Pod 被逐出或节点宕机等情况，你可能想访问应用日志。
|
||||
在集群中，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。
|
||||
这个概念叫 _集群级的日志_ 。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
Cluster-level logging architectures require a separate backend to store, analyze, and query logs. Kubernetes
|
||||
does not provide a native storage solution for log data. Instead, there are many logging solutions that
|
||||
integrate with Kubernetes. The following sections describe how to handle and store logs on nodes.
|
||||
-->
|
||||
集群级日志架构需要一个独立的后端用来存储、分析和查询日志。
|
||||
Kubernetes 并不为日志数据提供原生的存储解决方案。
|
||||
相反，有很多现成的日志方案可以集成到 Kubernetes 中。
|
||||
下面各节描述如何在节点上处理和存储日志。
|
||||
|
||||
<!--
|
||||
## Basic logging in Kubernetes
|
||||
|
||||
This example uses a `Pod` specification with a container
|
||||
to write text to the standard output stream once per second.
|
||||
-->
|
||||
## Kubernetes 中的基本日志记录
|
||||
|
||||
这里的示例使用包含一个容器的 Pod 规约，每秒钟向标准输出写入数据。
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
To run this pod, use the following command:
|
||||
-->
|
||||
用下面的命令运行 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is:
|
||||
-->
|
||||
输出结果为：
|
||||
|
||||
```
|
||||
pod/counter created
|
||||
```
|
||||
|
||||
<!--
|
||||
To fetch the logs, use the `kubectl logs` command, as follows:
|
||||
-->
|
||||
像下面这样，使用 `kubectl logs` 命令获取日志:
|
||||
|
||||
```shell
|
||||
kubectl logs counter
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is:
|
||||
-->
|
||||
输出结果为：
|
||||
|
||||
```
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container.
|
||||
If your pod has multiple containers, specify which container's logs you want to access by
|
||||
appending a container name to the command, with a `-c` flag, like so:
|
||||
-->
|
||||
你可以使用命令 `kubectl logs --previous` 检索之前容器实例的日志。
|
||||
如果 Pod 中有多个容器，你应该为该命令附加容器名以访问对应容器的日志。
|
||||
详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。
|
||||
如果 Pod 有多个容器，你应该为该命令附加容器名以访问对应容器的日志，
|
||||
使用 `-c` 标志来指定要访问的容器的日志，如下所示：
|
||||
|
||||
```console
|
||||
kubectl logs counter -c count
|
||||
```
|
||||
|
||||
<!--
|
||||
See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
-->
|
||||
详见 [`kubectl logs` 文档](/docs/reference/generated/kubectl/kubectl-commands#logs)。
|
||||
|
||||
<!--
|
||||
## Logging at the node level
|
||||
|
||||
|
||||
-->
|
||||
## 节点级日志记录
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
A container engine handles and redirects any output generated to a containerized application's `stdout` and `stderr` streams.
|
||||
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 容器引擎将这两个输出流重定向到某个
|
||||
[日志驱动（Logging Driver）](https://docs.docker.com/engine/admin/logging/overview) ，
|
||||
该日志驱动在 Kubernetes 中配置为以 JSON 格式写入文件。
|
||||
|
||||
<!--
|
||||
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 >}}
|
||||
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 中所有的容器也会被驱逐，包括容器日志。
|
||||
|
||||
<!--
|
||||
An important consideration in node-level logging is implementing log rotation,
|
||||
so that logs don't consume all available storage on the node. Kubernetes
|
||||
is not responsible for rotating logs, but rather a deployment tool
|
||||
should set up a solution to address that.
|
||||
For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
|
||||
there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
|
||||
tool configured to run each hour. You can also set up a container runtime to
|
||||
rotate application's logs automatically.
|
||||
-->
|
||||
节点级日志记录中，需要重点考虑实现日志的轮转，以此来保证日志不会消耗节点上全部可用空间。
|
||||
Kubernetes 并不负责轮转日志，而是通过部署工具建立一个解决问题的方案。
|
||||
例如，在用 `kube-up.sh` 部署的 Kubernetes 集群中，存在一个
|
||||
[`logrotate`](https://linux.die.net/man/8/logrotate)，每小时运行一次。
|
||||
你也可以设置容器运行时来自动地轮转应用日志。
|
||||
|
||||
<!--
|
||||
As an example, you can find detailed information about how `kube-up.sh` sets
|
||||
up logging for COS image on GCP in the corresponding
|
||||
[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh).
|
||||
-->
|
||||
例如，你可以找到关于 `kube-up.sh` 为 GCP 环境的 COS 镜像设置日志的详细信息，
|
||||
脚本为
|
||||
[`configure-helper` 脚本](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)。
|
||||
|
||||
<!--
|
||||
When using a **CRI container runtime**, the kubelet is responsible for rotating the logs and managing the logging directory structure. The kubelet
|
||||
sends this information to the CRI container runtime and the runtime writes the container logs to the given location.
|
||||
The two kubelet parameters [`containerLogMaxSize` and `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
in [kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
can be used to configure the maximum size for each log file and the maximum number of files allowed for each container respectively.
|
||||
-->
|
||||
当使用某 *CRI 容器运行时* 时，kubelet 要负责对日志进行轮换，并
|
||||
管理日志目录的结构。kubelet 将此信息发送给 CRI 容器运行时，后者
|
||||
将容器日志写入到指定的位置。在 [kubelet 配置文件](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
中的两个 kubelet 参数
|
||||
[`containerLogMaxSize` 和 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
可以用来配置每个日志文件的最大长度和每个容器可以生成的日志文件个数上限。
|
||||
|
||||
<!--
|
||||
When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
|
||||
the basic logging example, the kubelet on the node handles the request and
|
||||
reads directly from the log file. The kubelet returns the content of the log file.
|
||||
-->
|
||||
当运行 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) 时，
|
||||
节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。
|
||||
|
||||
<!--
|
||||
If an external system has performed the rotation or a CRI container runtime is used,
|
||||
only the contents of the latest log file will be available through
|
||||
`kubectl logs`. For example, if there's a 10MB file, `logrotate` performs
|
||||
the rotation and there are two files: one file that is 10MB in size and a second file that is empty.
|
||||
`kubectl logs` returns the latest log file which in this example is an empty response.
|
||||
-->
|
||||
{{< note >}}
|
||||
如果有外部系统执行日志轮转或者使用了 CRI 容器运行时，那么 `kubectl logs`
|
||||
仅可查询到最新的日志内容。
|
||||
比如，对于一个 10MB 大小的文件，通过 `logrotate` 执行轮转后生成两个文件，
|
||||
一个 10MB 大小，一个为空，`kubectl logs` 返回最新的日志文件，而该日志文件
|
||||
在这个例子中为空。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### System component logs
|
||||
|
||||
There are two types of system components: those that run in a container and those
|
||||
that do not run in a container. For example:
|
||||
-->
|
||||
### 系统组件日志
|
||||
|
||||
系统组件有两种类型：在容器中运行的和不在容器中运行的。例如：
|
||||
|
||||
<!--
|
||||
* The Kubernetes scheduler and kube-proxy run in a container.
|
||||
* The kubelet and container runtime do not run in containers.
|
||||
-->
|
||||
* 在容器中运行的 kube-scheduler 和 kube-proxy。
|
||||
* 不在容器中运行的 kubelet 和容器运行时。
|
||||
|
||||
<!--
|
||||
On machines with systemd, the kubelet and container runtime write to journald. If
|
||||
systemd is not present, the kubelet and container runtime write to `.log` files
|
||||
in the `/var/log` directory. System components inside containers always write
|
||||
to the `/var/log` directory, bypassing the default logging mechanism.
|
||||
They use the [`klog`](https://github.com/kubernetes/klog)
|
||||
logging library. You can find the conventions for logging severity for those
|
||||
components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
-->
|
||||
在使用 systemd 机制的服务器上，kubelet 和容器容器运行时将日志写入到 journald 中。
|
||||
如果没有 systemd，它们将日志写入到 `/var/log` 目录下的 `.log` 文件中。
|
||||
容器中的系统组件通常将日志写到 `/var/log` 目录，绕过了默认的日志机制。
|
||||
他们使用 [klog](https://github.com/kubernetes/klog) 日志库。
|
||||
你可以在[日志开发文档](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
|
||||
找到这些组件的日志告警级别约定。
|
||||
|
||||
<!--
|
||||
Similar to the container logs, system component logs in the `/var/log`
|
||||
directory should be rotated. In Kubernetes clusters brought up by
|
||||
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 时触发轮转。
|
||||
|
||||
<!--
|
||||
## 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没有为集群级日志记录提供原生的解决方案，但你可以考虑几种常见的方法。
|
||||
以下是一些选项：
|
||||
|
||||
* 使用在每个节点上运行的节点级日志记录代理。
|
||||
* 在应用程序的 Pod 中，包含专门记录日志的边车（Sidecar）容器。
|
||||
* 将日志直接从应用程序中推送到日志记录后端。
|
||||
|
||||
<!--
|
||||
### Using a node logging agent
|
||||
|
||||
|
||||
-->
|
||||
### 使用节点级日志代理
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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 run the agent
|
||||
as a `DaemonSet`.
|
||||
Node-level logging creates only one agent per node, and doesn't require any changes to the applications running on the node.
|
||||
-->
|
||||
由于日志记录代理必须在每个节点上运行，通常可以用 `DaemonSet` 的形式运行该代理。
|
||||
节点级日志在每个节点上仅创建一个代理，不需要对节点上的应用做修改。
|
||||
|
||||
<!--
|
||||
Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation.
|
||||
-->
|
||||
容器向标准输出和标准错误输出写出数据，但在格式上并不统一。
|
||||
节点级代理
|
||||
收集这些日志并将其进行转发以完成汇总。
|
||||
|
||||
<!--
|
||||
### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent}
|
||||
|
||||
You can use a sidecar container in one of the following ways:
|
||||
-->
|
||||
### 使用 sidecar 容器运行日志代理 {#sidecar-container-with-logging-agent}
|
||||
|
||||
你可以通过以下方式之一使用边车（Sidecar）容器：
|
||||
|
||||
<!--
|
||||
* The sidecar container streams application logs to its own `stdout`.
|
||||
* The sidecar container runs a logging agent, which is configured to pick up logs from an application container.
|
||||
-->
|
||||
* 边车容器将应用程序日志传送到自己的标准输出。
|
||||
* 边车容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。
|
||||
|
||||
<!--
|
||||
#### Streaming sidecar container
|
||||
|
||||
|
||||
|
||||
By having your sidecar containers stream to their own `stdout` and `stderr`
|
||||
streams, you can take advantage of the kubelet and the logging agent that
|
||||
already run on each node. The sidecar containers read logs from a file, a socket,
|
||||
or the journald. Each sidecar container prints log to its own `stdout` or `stderr` stream.
|
||||
-->
|
||||
#### 传输数据流的 sidecar 容器
|
||||
|
||||
|
||||
|
||||
利用边车容器向自己的 `stdout` 和 `stderr` 传输流的方式，
|
||||
你就可以利用每个节点上的 kubelet 和日志代理来处理日志。
|
||||
边车容器从文件、套接字或 journald 读取日志。
|
||||
每个边车容器向自己的 `stdout` 和 `stderr` 流中输出日志。
|
||||
|
||||
<!--
|
||||
This approach allows you to separate several log streams from different
|
||||
parts of your application, some of which can lack support
|
||||
for writing to `stdout` or `stderr`. The logic behind redirecting logs
|
||||
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` 由 kubelet 处理，你可以使用内置的工具 `kubectl logs`。
|
||||
|
||||
<!--
|
||||
For example, a pod runs a single container, and the container
|
||||
writes to two different log files, using two different formats. Here's a
|
||||
configuration file for the Pod:
|
||||
-->
|
||||
例如，某 Pod 中运行一个容器，该容器向两个文件写不同格式的日志。
|
||||
下面是这个 pod 的配置文件:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
<!--
|
||||
It is not recommended to write log entries with different formats to the same log
|
||||
stream, even if you managed to redirect both components to the `stdout` stream of
|
||||
the container. Instead, you can create 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` 流。相反，你可以创建两个边车容器。每个边车容器可以从共享卷
|
||||
跟踪特定的日志文件，并将文件内容重定向到各自的 `stdout` 流。
|
||||
|
||||
<!--
|
||||
Here's a configuration file for a pod that has two sidecar containers:
|
||||
-->
|
||||
下面是运行两个边车容器的 Pod 的配置文件：
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
<!--
|
||||
Now when you run this pod, you can access each log stream separately by
|
||||
running the following commands:
|
||||
-->
|
||||
现在当你运行这个 Pod 时，你可以运行如下命令分别访问每个日志流：
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-1
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is:
|
||||
-->
|
||||
输出为：
|
||||
|
||||
```console
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-2
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is:
|
||||
-->
|
||||
输出为：
|
||||
|
||||
```console
|
||||
Mon Jan 1 00:00:00 UTC 2001 INFO 0
|
||||
Mon Jan 1 00:00:01 UTC 2001 INFO 1
|
||||
Mon Jan 1 00:00:02 UTC 2001 INFO 2
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
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
|
||||
for cpu and order of several megabytes for memory), writing logs to a file and
|
||||
then streaming them to `stdout` can double disk usage. If you have
|
||||
an application that writes to a single file, it's generally better to set
|
||||
`/dev/stdout` as destination rather than implementing the streaming sidecar
|
||||
container approach.
|
||||
-->
|
||||
注意，尽管 CPU 和内存使用率都很低（以多个 CPU 毫核指标排序或者按内存的兆字节排序），
|
||||
向文件写日志然后输出到 `stdout` 流仍然会成倍地增加磁盘使用率。
|
||||
如果你的应用向单一文件写日志，通常最好设置 `/dev/stdout` 作为目标路径，
|
||||
而不是使用流式的边车容器方式。
|
||||
|
||||
<!--
|
||||
Sidecar containers can also be used to rotate log files that cannot be
|
||||
rotated by the application itself. An example of this approach is a small container running logrotate periodically.
|
||||
However, it's recommended to use `stdout` and `stderr` directly and leave rotation
|
||||
and retention policies to the kubelet.
|
||||
-->
|
||||
应用本身如果不具备轮转日志文件的功能，可以通过边车容器实现。
|
||||
该方式的一个例子是运行一个小的、定期轮转日志的容器。
|
||||
然而，还是推荐直接使用 `stdout` 和 `stderr`，将日志的轮转和保留策略
|
||||
交给 kubelet。
|
||||
|
||||
<!--
|
||||
#### Sidecar container with a logging agent
|
||||
|
||||
|
||||
-->
|
||||
### 具有日志代理功能的边车容器
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个
|
||||
带有单独日志记录代理的边车容器，将代理程序专门配置为与你的应用程序一起运行。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Using a logging agent in a sidecar container can lead
|
||||
to significant resource consumption. Moreover, you won't be able to access
|
||||
those logs using `kubectl logs` command, because they are not controlled
|
||||
by the kubelet.
|
||||
-->
|
||||
在边车容器中使用日志代理会带来严重的资源损耗。
|
||||
此外，你不能使用 `kubectl logs` 命令访问日志，因为日志并没有被 kubelet 管理。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Here are two configuration files that you can use to implement a sidecar container with a logging agent. The first file contains
|
||||
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
|
||||
-->
|
||||
下面是两个配置文件，可以用来实现一个带日志代理的边车容器。
|
||||
第一个文件包含用来配置 fluentd 的
|
||||
[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
For information about configuring fluentd, see the [fluentd documentation](https://docs.fluentd.org/).
|
||||
-->
|
||||
要进一步了解如何配置 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 边车容器的 Pod 。
|
||||
flutend 通过 Pod 的挂载卷获取它的配置数据。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
|
||||
<!--
|
||||
In the sample configurations, you can replace fluentd with any logging agent, reading from any source inside an application container.
|
||||
-->
|
||||
在示例配置中，你可以将 fluentd 替换为任何日志代理，从应用容器内
|
||||
的任何来源读取数据。
|
||||
|
||||
<!--
|
||||
### Exposing logs directly from the application
|
||||
|
||||
|
||||
-->
|
||||
### 从应用中直接暴露日志目录
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Cluster-logging that exposes or pushes logs directly from every application is outside the scope of Kubernetes.
|
||||
-->
|
||||
从各个应用中直接暴露和推送日志数据的集群日志机制
|
||||
已超出 Kubernetes 的范围。
|
||||
|
||||
@@ -0,0 +1,728 @@
|
||||
---
|
||||
title: 管理资源
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/).
|
||||
-->
|
||||
你已经部署了应用并通过服务暴露它。然后呢？
|
||||
Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。
|
||||
我们将更深入讨论的特性包括
|
||||
[配置文件](/zh/docs/concepts/configuration/overview/)和
|
||||
[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Organizing resource configurations
|
||||
|
||||
Many applications require multiple resources to be created, such as a Deployment and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by in YAML). For example:
|
||||
-->
|
||||
## 组织资源配置
|
||||
|
||||
许多应用需要创建多个资源，例如 Deployment 和 Service。
|
||||
可以通过将多个资源组合在同一个文件中（在 YAML 中以 `---` 分隔）
|
||||
来简化对它们的管理。例如：
|
||||
|
||||
{{< codenew file="application/nginx-app.yaml" >}}
|
||||
|
||||
<!--
|
||||
Multiple resources can be created the same way as a single resource:
|
||||
-->
|
||||
可以用创建单个资源相同的方式来创建多个资源：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
```
|
||||
|
||||
```
|
||||
service/my-nginx-svc created
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
The resources will be created in the order they appear in the file. Therefore, it's best to specify the service first, since that will ensure the scheduler can spread the pods associated with the service as they are created by the controller(s), such as Deployment.
|
||||
-->
|
||||
资源将按照它们在文件中的顺序创建。
|
||||
因此，最好先指定服务，这样在控制器（例如 Deployment）创建 Pod 时能够
|
||||
确保调度器可以将与服务关联的多个 Pod 分散到不同节点。
|
||||
|
||||
<!--
|
||||
`kubectl apply` also accepts multiple `-f` arguments:
|
||||
-->
|
||||
`kubectl create` 也接受多个 `-f` 参数:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
And a directory can be specified rather than or in addition to individual files:
|
||||
-->
|
||||
还可以指定目录路径，而不用添加多个单独的文件：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/
|
||||
```
|
||||
|
||||
<!--
|
||||
`kubectl` will read any files with suffixes `.yaml`, `.yml`, or `.json`.
|
||||
|
||||
It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory. If the tiers of your application bind to each other using DNS, then you can deploy all of the components of your stack together.
|
||||
|
||||
A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into Github:
|
||||
-->
|
||||
`kubectl` 将读取任何后缀为 `.yaml`、`.yml` 或者 `.json` 的文件。
|
||||
|
||||
建议的做法是，将同一个微服务或同一应用层相关的资源放到同一个文件中，
|
||||
将同一个应用相关的所有文件按组存放到同一个目录中。
|
||||
如果应用的各层使用 DNS 相互绑定，那么你可以将堆栈的所有组件一起部署。
|
||||
|
||||
还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
## Bulk operations in kubectl
|
||||
|
||||
Resource creation isn't the only operation that `kubectl` can perform in bulk. It can also extract resource names from configuration files in order to perform other operations, in particular to delete the same resources you created:
|
||||
-->
|
||||
## kubectl 中的批量操作
|
||||
|
||||
资源创建并不是 `kubectl` 可以批量执行的唯一操作。
|
||||
`kubectl` 还可以从配置文件中提取资源名，以便执行其他操作，
|
||||
特别是删除你之前创建的资源：
|
||||
|
||||
```shell
|
||||
kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
||||
<!--
|
||||
In the case of two resources, it's also easy to specify both on the command line using the resource/name syntax:
|
||||
-->
|
||||
在仅有两种资源的情况下，可以使用"资源类型/资源名"的语法在命令行中
|
||||
同时指定这两个资源：
|
||||
|
||||
```shell
|
||||
kubectl delete deployments/my-nginx services/my-nginx-svc
|
||||
```
|
||||
|
||||
<!--
|
||||
For larger numbers of resources, you'll find it easier to specify the selector (label query) specified using `-l` or `--selector`, to filter resources by their labels:
|
||||
-->
|
||||
对于资源数目较大的情况，你会发现使用 `-l` 或 `--selector`
|
||||
指定筛选器（标签查询）能很容易根据标签筛选资源：
|
||||
|
||||
```shell
|
||||
kubectl delete deployment,services -l app=nginx
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
||||
<!--
|
||||
Because `kubectl` outputs resource names in the same syntax it accepts, you can chain operations using `$()` or `xargs`:
|
||||
-->
|
||||
由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同，
|
||||
你可以使用 `$()` 或 `xargs` 进行链式操作：
|
||||
|
||||
```shell
|
||||
kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
|
||||
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
|
||||
```
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
||||
```
|
||||
|
||||
<!--
|
||||
With the above commands, we first create resources under `examples/application/nginx/` and print the resources created with `-o name` output format
|
||||
(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`.
|
||||
-->
|
||||
上面的命令中，我们首先使用 `examples/application/nginx/` 下的配置文件创建资源，
|
||||
并使用 `-o name` 的输出格式（以"资源/名称"的形式打印每个资源）打印所创建的资源。
|
||||
然后，我们通过 `grep` 来过滤 "service"，最后再打印 `kubectl get` 的内容。
|
||||
|
||||
<!--
|
||||
If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag.
|
||||
-->
|
||||
如果你碰巧在某个路径下的多个子路径中组织资源，那么也可以递归地在所有子路径上
|
||||
执行操作，方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。
|
||||
|
||||
<!--
|
||||
For instance, assume there is a directory `project/k8s/development` that holds all of the manifests needed for the development environment, organized by resource type:
|
||||
-->
|
||||
例如，假设有一个目录路径为 `project/k8s/development`，它保存开发环境所需的
|
||||
所有清单，并按资源类型组织：
|
||||
|
||||
```
|
||||
project/k8s/development
|
||||
├── configmap
|
||||
│ └── my-configmap.yaml
|
||||
├── deployment
|
||||
│ └── my-deployment.yaml
|
||||
└── pvc
|
||||
└── my-pvc.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we had tried to create the resources in this directory using the following command, we would have encountered an error:
|
||||
-->
|
||||
默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级，
|
||||
而不是处理所有子目录。
|
||||
如果我们试图使用以下命令在此目录中创建资源，则会遇到一个错误：
|
||||
|
||||
```shell
|
||||
kubectl apply -f project/k8s/development
|
||||
```
|
||||
|
||||
```
|
||||
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
||||
```
|
||||
|
||||
<!--
|
||||
Instead, specify the `--recursive` or `-R` flag with the `--filename,-f` flag as such:
|
||||
-->
|
||||
正确的做法是，在 `--filename,-f` 后面标明 `--recursive` 或者 `-R` 之后：
|
||||
|
||||
```shell
|
||||
kubectl apply -f project/k8s/development --recursive
|
||||
```
|
||||
|
||||
```
|
||||
configmap/my-config created
|
||||
deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
<!--
|
||||
The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout} etc.`
|
||||
|
||||
The `--recursive` flag also works when multiple `-f` arguments are provided:
|
||||
-->
|
||||
`--recursive` 可以用于接受 `--filename,-f` 参数的任何操作，例如：
|
||||
`kubectl {create,get,delete,describe,rollout}` 等。
|
||||
|
||||
有多个 `-f` 参数出现的时候，`--recursive` 参数也能正常工作：
|
||||
|
||||
```shell
|
||||
kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive
|
||||
```
|
||||
|
||||
```
|
||||
namespace/development created
|
||||
namespace/staging created
|
||||
configmap/my-config created
|
||||
deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
<!--
|
||||
If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/).
|
||||
-->
|
||||
如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读
|
||||
[命令行工具（kubectl）](/zh/docs/reference/kubectl/)。
|
||||
|
||||
<!--
|
||||
## Using labels effectively
|
||||
|
||||
The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.
|
||||
-->
|
||||
## 有效地使用标签
|
||||
|
||||
到目前为止我们使用的示例中的资源最多使用了一个标签。
|
||||
在许多情况下，应使用多个标签来区分集合。
|
||||
|
||||
<!--
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
-->
|
||||
例如，不同的应用可能会为 `app` 标签设置不同的值。
|
||||
但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/master/guestbook/)
|
||||
这样的多层应用，还需要区分每一层。前端可以带以下标签：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
while the Redis master and slave would have different `tier` labels, and perhaps even an additional `role` label:
|
||||
-->
|
||||
Redis 的主节点和从节点会有不同的 `tier` 标签，甚至还有一个额外的 `role` 标签：
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: master
|
||||
```
|
||||
|
||||
<!-- and -->
|
||||
以及
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: slave
|
||||
```
|
||||
|
||||
<!--
|
||||
The labels allow us to slice and dice our resources along any dimension specified by a label:
|
||||
-->
|
||||
标签允许我们按照标签指定的任何维度对我们的资源进行切片和切块：
|
||||
|
||||
```shell
|
||||
kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
|
||||
kubectl get pods -Lapp -Ltier -Lrole
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE APP TIER ROLE
|
||||
guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master
|
||||
guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave
|
||||
guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave
|
||||
my-nginx-divi2 1/1 Running 0 29m nginx <none> <none>
|
||||
my-nginx-o0ef1 1/1 Running 0 29m nginx <none> <none>
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get pods -lapp=guestbook,role=slave
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
guestbook-redis-slave-2q2yf 1/1 Running 0 3m
|
||||
guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
||||
```
|
||||
|
||||
<!--
|
||||
## Canary deployments
|
||||
|
||||
Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
|
||||
-->
|
||||
## 金丝雀部署（Canary Deployments） {#canary-deployments}
|
||||
|
||||
另一个需要多标签的场景是用来区分同一组件的不同版本或者不同配置的多个部署。
|
||||
常见的做法是部署一个使用*金丝雀发布*来部署新应用版本
|
||||
（在 Pod 模板中通过镜像标签指定），保持新旧版本应用同时运行。
|
||||
这样，新版本在完全发布之前也可以接收实时的生产流量。
|
||||
|
||||
<!--
|
||||
For instance, you can use a `track` label to differentiate different releases.
|
||||
|
||||
The primary, stable release would have a `track` label with value as `stable`:
|
||||
-->
|
||||
例如，你可以使用 `track` 标签来区分不同的版本。
|
||||
|
||||
主要稳定的发行版将有一个 `track` 标签，其值为 `stable`：
|
||||
|
||||
```yaml
|
||||
name: frontend
|
||||
replicas: 3
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: stable
|
||||
...
|
||||
image: gb-frontend:v3
|
||||
```
|
||||
|
||||
<!--
|
||||
and then you can create a new release of the guestbook frontend that carries the `track` label with different value (i.e. `canary`), so that two sets of pods would not overlap:
|
||||
-->
|
||||
然后，你可以创建 guestbook 前端的新版本，让这些版本的 `track` 标签带有不同的值
|
||||
（即 `canary`），以便两组 Pod 不会重叠：
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
replicas: 1
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: canary
|
||||
...
|
||||
image: gb-frontend:v4
|
||||
```
|
||||
|
||||
<!--
|
||||
The frontend service would span both sets of replicas by selecting the common subset of their labels (i.e. omitting the `track` label), so that the traffic will be redirected to both applications:
|
||||
-->
|
||||
前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本，
|
||||
以便流量可以转发到两个应用：
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
|
||||
Once you're confident, you can update the stable track to the new application release and remove the canary one.
|
||||
-->
|
||||
你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收
|
||||
实时生产流量的比例（在本例中为 3:1）。
|
||||
一旦有信心，你就可以将新版本应用的 `track` 标签的值从
|
||||
`canary` 替换为 `stable`，并且将老版本应用删除。
|
||||
|
||||
<!--
|
||||
For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
|
||||
-->
|
||||
想要了解更具体的示例，请查看
|
||||
[Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。
|
||||
|
||||
<!--
|
||||
## Updating labels
|
||||
|
||||
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
|
||||
For example, if you want to label all your nginx pods as frontend tier, run:
|
||||
-->
|
||||
## 更新标签 {#updating-labels}
|
||||
|
||||
有时，现有的 pod 和其它资源需要在创建新资源之前重新标记。
|
||||
这可以用 `kubectl label` 完成。
|
||||
例如，如果想要将所有 nginx pod 标记为前端层，运行：
|
||||
|
||||
```shell
|
||||
kubectl label pods -l app=nginx tier=fe
|
||||
```
|
||||
|
||||
```
|
||||
pod/my-nginx-2035384211-j5fhi labeled
|
||||
pod/my-nginx-2035384211-u2c7e labeled
|
||||
pod/my-nginx-2035384211-u3t6x labeled
|
||||
```
|
||||
|
||||
<!--
|
||||
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
|
||||
To see the pods you labeled, run:
|
||||
-->
|
||||
首先用标签 "app=nginx" 过滤所有的 Pod，然后用 "tier=fe" 标记它们。
|
||||
想要查看你刚才标记的 Pod，请运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=nginx -L tier
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE TIER
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe
|
||||
my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
|
||||
my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
||||
```
|
||||
|
||||
<!--
|
||||
This outputs all "app=nginx" pods, with an additional label column of pods' tier (specified with `-L` or `--label-columns`).
|
||||
|
||||
For more information, please see [labels](/docs/concepts/overview/working-with-objects/labels/) and [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
|
||||
-->
|
||||
这将输出所有 "app=nginx" 的 Pod，并有一个额外的描述 Pod 的 tier 的标签列
|
||||
（用参数 `-L` 或者 `--label-columns` 标明）。
|
||||
|
||||
想要了解更多信息，请参考
|
||||
[标签](/zh/docs/concepts/overview/working-with-objects/labels/) 和
|
||||
[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands/#label)
|
||||
命令文档。
|
||||
|
||||
<!--
|
||||
## Updating annotations
|
||||
|
||||
Sometimes you would want to attach annotations to resources. Annotations are arbitrary non-identifying metadata for retrieval by API clients such as tools, libraries, etc. This can be done with `kubectl annotate`. For example:
|
||||
-->
|
||||
## 更新注解 {#updating-annotations}
|
||||
|
||||
有时，你可能希望将注解附加到资源中。注解是 API 客户端（如工具、库等）
|
||||
用于检索的任意非标识元数据。这可以通过 `kubectl annotate` 来完成。例如：
|
||||
|
||||
```shell
|
||||
kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
||||
kubectl get pods my-nginx-v4-9gw19 -o yaml
|
||||
```
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: pod
|
||||
metadata:
|
||||
annotations:
|
||||
description: my frontend running nginx
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
For more information, please see [annotations](/docs/concepts/overview/working-with-objects/annotations/) and [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) document.
|
||||
-->
|
||||
想要了解更多信息，请参考
|
||||
[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和
|
||||
[`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate)
|
||||
命令文档。
|
||||
|
||||
<!--
|
||||
## Scaling your application
|
||||
|
||||
When load on your application grows or shrinks, use `kubectl` to scale you application. For instance, to decrease the number of nginx replicas from 3 to 1, do:
|
||||
-->
|
||||
## 扩缩你的应用
|
||||
|
||||
当应用上的负载增长或收缩时，使用 `kubectl` 能够实现应用规模的扩缩。
|
||||
例如，要将 nginx 副本的数量从 3 减少到 1，请执行以下操作：
|
||||
|
||||
```shell
|
||||
kubectl scale deployment/my-nginx --replicas=1
|
||||
```
|
||||
|
||||
```
|
||||
deployment.extensions/my-nginx scaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Now you only have one pod managed by the deployment.
|
||||
-->
|
||||
现在，你的 Deployment 管理的 Pod 只有一个了。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 30m
|
||||
```
|
||||
|
||||
<!--
|
||||
To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do:
|
||||
-->
|
||||
想要让系统自动选择需要 nginx 副本的数量，范围从 1 到 3，请执行以下操作：
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment/my-nginx --min=1 --max=3
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/my-nginx autoscaled
|
||||
```
|
||||
|
||||
<!--
|
||||
Now your nginx replicas will be scaled up and down as needed, automatically.
|
||||
|
||||
For more information, please see [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document.
|
||||
-->
|
||||
现在，你的 nginx 副本将根据需要自动地增加或者减少。
|
||||
|
||||
想要了解更多信息，请参考
|
||||
[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、
|
||||
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和
|
||||
[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。
|
||||
|
||||
<!--
|
||||
## In-place updates of resources
|
||||
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
|
||||
-->
|
||||
## 就地更新资源 {#in-place-updates-of-resources}
|
||||
|
||||
有时，有必要对你所创建的资源进行小范围、无干扰地更新。
|
||||
|
||||
### kubectl apply
|
||||
|
||||
<!--
|
||||
It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)),
|
||||
so that they can be maintained and versioned along with the code for the resources they configure.
|
||||
Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to push your configuration changes to the cluster.
|
||||
-->
|
||||
建议在源代码管理中维护一组配置文件
|
||||
（参见[配置即代码](https://martinfowler.com/bliki/InfrastructureAsCode.html)），
|
||||
这样，它们就可以和应用代码一样进行维护和版本管理。
|
||||
然后，你可以用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)
|
||||
将配置变更应用到集群中。
|
||||
|
||||
<!--
|
||||
This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
|
||||
-->
|
||||
这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改，
|
||||
但是不会自动覆盖任何你没有指定更改的属性。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
deployment.apps/my-nginx configured
|
||||
```
|
||||
|
||||
<!--
|
||||
Note that `kubectl apply` attaches an annotation to the resource in order to determine the changes to the configuration since the previous invocation. When it's invoked, `kubectl apply` does a three-way diff between the previous configuration, the provided input and the current configuration of the resource, in order to determine how to modify the resource.
|
||||
-->
|
||||
注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。
|
||||
执行时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间
|
||||
找出三方差异，以确定如何修改资源。
|
||||
|
||||
<!--
|
||||
Currently, resources are created without this annotation, so the first invocation of `kubectl apply` will fall back to a two-way diff between the provided input and the current configuration of the resource. During this first invocation, it cannot detect the deletion of properties set when the resource was created. For this reason, it will not remove them.
|
||||
-->
|
||||
目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 时
|
||||
将使用提供的输入和资源的当前配置双方之间差异进行比较。
|
||||
在第一次调用期间，它无法检测资源创建时属性集的删除情况。
|
||||
因此，kubectl 不会删除它们。
|
||||
|
||||
<!--
|
||||
All subsequent calls to `kubectl apply`, and other commands that modify the configuration, such as `kubectl replace` and `kubectl edit`, will update the annotation, allowing subsequent calls to `kubectl apply` to detect and perform deletions using a three-way diff.
|
||||
-->
|
||||
所有后续的 `kubectl apply` 操作以及其他修改配置的命令，如 `kubectl replace`
|
||||
和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply`
|
||||
使用三方差异进行检查和执行删除。
|
||||
|
||||
<!--
|
||||
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||
-->
|
||||
{{< note >}}
|
||||
想要使用 apply，请始终使用 `kubectl apply` 或 `kubectl create --save-config` 创建资源。
|
||||
{{< /note >}}
|
||||
|
||||
### kubectl edit
|
||||
|
||||
<!--
|
||||
Alternatively, you may also update resources with `kubectl edit`:
|
||||
-->
|
||||
或者，你也可以使用 `kubectl edit` 更新资源：
|
||||
|
||||
```shell
|
||||
kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
This is equivalent to first `get` the resource, edit it in text editor, and then `apply` the resource with the updated version:
|
||||
-->
|
||||
这相当于首先 `get` 资源，在文本编辑器中编辑它，然后用更新的版本 `apply` 资源：
|
||||
|
||||
```shell
|
||||
kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
|
||||
vi /tmp/nginx.yaml
|
||||
# do some edit, and then save the file
|
||||
|
||||
kubectl apply -f /tmp/nginx.yaml
|
||||
deployment.apps/my-nginx configured
|
||||
|
||||
rm /tmp/nginx.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
This allows you to do more significant changes more easily. Note that you can specify the editor with your `EDITOR` or `KUBE_EDITOR` environment variables.
|
||||
|
||||
For more information, please see [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) document.
|
||||
-->
|
||||
这使你可以更加容易地进行更重大的更改。
|
||||
请注意，可以使用 `EDITOR` 或 `KUBE_EDITOR` 环境变量来指定编辑器。
|
||||
|
||||
想要了解更多信息，请参考
|
||||
[kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 文档。
|
||||
|
||||
### kubectl patch
|
||||
|
||||
<!--
|
||||
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
|
||||
JSON merge patch, and strategic merge patch. See
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
and
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
-->
|
||||
你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、
|
||||
JSON merge patch、以及 strategic merge patch。 请参考
|
||||
[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
和
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
|
||||
<!--
|
||||
## Disruptive updates
|
||||
|
||||
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may want to make a recursive change immediately, such as to fix broken pods created by a Deployment. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can modify your original configuration file:
|
||||
-->
|
||||
## 破坏性的更新 {#disruptive-updates}
|
||||
|
||||
在某些情况下，你可能需要更新某些初始化后无法更新的资源字段，或者你可能只想立即进行递归更改，
|
||||
例如修复 Deployment 创建的不正常的 Pod。若要更改这些字段，请使用 `replace --force`，
|
||||
它将删除并重新创建资源。在这种情况下，你可以修改原始配置文件：
|
||||
|
||||
```shell
|
||||
kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/my-nginx deleted
|
||||
deployment.apps/my-nginx replaced
|
||||
```
|
||||
|
||||
<!--
|
||||
## Updating your application without a service outage
|
||||
-->
|
||||
## 在不中断服务的情况下更新应用
|
||||
|
||||
<!--
|
||||
At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
|
||||
-->
|
||||
在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签，
|
||||
如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作，
|
||||
每种更新操作都适用于不同的场景。
|
||||
|
||||
<!--
|
||||
We'll guide you through how to create and update applications with Deployments.
|
||||
-->
|
||||
我们将指导你通过 Deployment 如何创建和更新应用。
|
||||
|
||||
<!--
|
||||
Let's say you were running version 1.14.2 of nginx:
|
||||
-->
|
||||
假设你正运行的是 1.14.2 版本的 nginx：
|
||||
|
||||
```shell
|
||||
kubectl create deployment my-nginx --image=nginx:1.14.2
|
||||
```
|
||||
```
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
To update to version 1.16.1, change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`, with the previous kubectl commands.
|
||||
-->
|
||||
要更新到 1.16.1 版本，只需使用我们前面学到的 kubectl 命令将
|
||||
`.spec.template.spec.containers[0].image` 从 `nginx:1.14.2` 修改为 `nginx:1.16.1`。
|
||||
|
||||
```shell
|
||||
kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/).
|
||||
-->
|
||||
没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。
|
||||
它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。
|
||||
想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug/debug-application/debug-running-pod/)
|
||||
- [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/)
|
||||
-->
|
||||
- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug/debug-application/debug-running-pod/)
|
||||
- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/)
|
||||
@@ -0,0 +1,480 @@
|
||||
---
|
||||
title: 集群网络系统
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- thockin
|
||||
title: Cluster Networking
|
||||
content_type: concept
|
||||
weight: 50
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Networking is a central part of Kubernetes, but it can be challenging to
|
||||
understand exactly how it is expected to work. There are 4 distinct networking
|
||||
problems to address:
|
||||
|
||||
1. Highly-coupled container-to-container communications: this is solved by
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications.
|
||||
2. Pod-to-Pod communications: this is the primary focus of this document.
|
||||
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
|
||||
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
集群网络系统是 Kubernetes 的核心部分，但是想要准确了解它的工作原理可是个不小的挑战。
|
||||
下面列出的是网络系统的的四个主要问题：
|
||||
|
||||
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/)负责。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
Kubernetes is all about sharing machines between applications. Typically,
|
||||
sharing machines requires ensuring that two applications do not try to use the
|
||||
same ports. Coordinating ports across multiple developers is very difficult to
|
||||
do at scale and exposes users to cluster-level issues outside of their control.
|
||||
|
||||
Dynamic port allocation brings a lot of complications to the system - every
|
||||
application has to take ports as flags, the API servers have to know how to
|
||||
insert dynamic port numbers into configuration blocks, services have to know
|
||||
how to find each other, etc. Rather than deal with this, Kubernetes takes a
|
||||
different approach.
|
||||
|
||||
To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/).
|
||||
-->
|
||||
Kubernetes 的宗旨就是在应用之间共享机器。
|
||||
通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间
|
||||
去大规模地协调端口是件很困难的事情，尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。
|
||||
|
||||
动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数，
|
||||
而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。
|
||||
与其去解决这些问题，Kubernetes 选择了其他不同的方法。
|
||||
|
||||
要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。
|
||||
<!--
|
||||
## How to implement the Kubernetes networking model
|
||||
|
||||
There are a number of ways that this network model can be implemented. This
|
||||
document is not an exhaustive study of the various methods, but hopefully serves
|
||||
as an introduction to various technologies and serves as a jumping-off point.
|
||||
|
||||
The following networking options are sorted alphabetically - the order does not
|
||||
imply any preferential status.
|
||||
-->
|
||||
## 如何实现 Kubernetes 的网络模型 {#how-to-implement-the-kubernetes-networking-model}
|
||||
|
||||
有很多种方式可以实现这种网络模型，本文档并不是对各种实现技术的详细研究，
|
||||
但是希望可以作为对各种技术的详细介绍，并且成为你研究的起点。
|
||||
|
||||
接下来的网络技术是按照首字母排序，顺序本身并无其他意义。
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
<!--
|
||||
### ACI
|
||||
|
||||
[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).
|
||||
-->
|
||||
### ACI
|
||||
[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html)
|
||||
提供了一个集成覆盖网络和底层 SDN 的解决方案来支持容器、虚拟机和其他裸机服务器。
|
||||
[ACI](https://www.github.com/noironetworks/aci-containers) 为 ACI 提供了容器网络集成。
|
||||
点击[这里](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)查看概述。
|
||||
|
||||
<!--
|
||||
### Antrea
|
||||
|
||||
Project [Antrea](https://github.com/vmware-tanzu/antrea) is an opensource Kubernetes networking solution intended to be Kubernetes native. It leverages Open vSwitch as the networking data plane. Open vSwitch is a high-performance programmable virtual switch that supports both Linux and Windows. Open vSwitch enables Antrea to implement Kubernetes Network Policies in a high-performance and efficient manner.
|
||||
Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to implement an extensive set of networking and security features and services on top of Open vSwitch.
|
||||
-->
|
||||
### Antrea
|
||||
|
||||
[Antrea](https://github.com/vmware-tanzu/antrea) 项目是一个开源的联网解决方案，旨在成为
|
||||
Kubernetes 原生的网络解决方案。它利用 Open vSwitch 作为网络数据平面。
|
||||
Open vSwitch 是一个高性能可编程的虚拟交换机，支持 Linux 和 Windows 平台。
|
||||
Open vSwitch 使 Antrea 能够以高性能和高效的方式实现 Kubernetes 的网络策略。
|
||||
借助 Open vSwitch 可编程的特性，Antrea 能够在 Open vSwitch 之上实现广泛的联网、安全功能和服务。
|
||||
|
||||
<!--
|
||||
### AWS VPC CNI for Kubernetes
|
||||
|
||||
The [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) offers integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. This CNI plugin offers high throughput and availability, low latency, and minimal network jitter. Additionally, users can apply existing AWS VPC networking and security best practices for building Kubernetes clusters. This includes the ability to use VPC flow logs, VPC routing policies, and security groups for network traffic isolation.
|
||||
|
||||
Using this CNI plugin allows Kubernetes pods to have the same IP address inside the pod as they do on the VPC network. The CNI allocates AWS Elastic Networking Interfaces (ENIs) to each Kubernetes node and using the secondary IP range from each ENI for pods on the node. The CNI includes controls for pre-allocation of ENIs and IP addresses for fast pod startup times and enables large clusters of up to 2,000 nodes.
|
||||
|
||||
Additionally, the CNI can be run alongside [Calico for network policy enforcement](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). The AWS VPC CNI project is open source with [documentation on GitHub](https://github.com/aws/amazon-vpc-cni-k8s).
|
||||
-->
|
||||
### Kubernetes 的 AWS VPC CNI {#aws-vpc-cni-for-kubernetes}
|
||||
|
||||
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) 为 Kubernetes 集群提供了集成的
|
||||
AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可用性，低延迟以及最小的网络抖动。
|
||||
此外，用户可以使用现有的 AWS VPC 网络和安全最佳实践来构建 Kubernetes 集群。
|
||||
这包括使用 VPC 流日志、VPC 路由策略和安全组进行网络流量隔离的功能。
|
||||
|
||||
使用该 CNI 插件，可使 Kubernetes Pod 拥有与在 VPC 网络上相同的 IP 地址。
|
||||
CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod。
|
||||
CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达 2000 个节点的大型集群。
|
||||
|
||||
此外，CNI 可以与
|
||||
[用于执行网络策略的 Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) 一起运行。
|
||||
AWS VPC CNI 项目是开源的，请查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。
|
||||
|
||||
<!--
|
||||
### Azure CNI for Kubernetes
|
||||
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
|
||||
|
||||
Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
|
||||
-->
|
||||
### Kubernetes 的 Azure CNI {#azure-cni-for-kubernetes}
|
||||
|
||||
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview)
|
||||
是一个[开源插件](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)，
|
||||
将 Kubernetes Pods 和 Azure 虚拟网络（也称为 VNet）集成在一起，可提供与 VM 相当的网络性能。
|
||||
Pod 可以通过 Express Route 或者 站点到站点的 VPN 来连接到对等的 VNet，
|
||||
也可以从这些网络来直接访问 Pod。Pod 可以访问受服务端点或者受保护链接的 Azure 服务，比如存储和 SQL。
|
||||
你可以使用 VNet 安全策略和路由来筛选 Pod 流量。
|
||||
该插件通过利用在 Kubernetes 节点的网络接口上预分配的辅助 IP 池将 VNet 分配给 Pod。
|
||||
|
||||
Azure CNI 可以在
|
||||
[Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) 中获得。
|
||||
|
||||
<!--
|
||||
### Calico
|
||||
|
||||
[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
|
||||
-->
|
||||
### Calico
|
||||
|
||||
[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) 是一个开源的联网及网络安全方案，
|
||||
用于基于容器、虚拟机和本地主机的工作负载。
|
||||
Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面
|
||||
以及 Windows HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与
|
||||
[云驱动 CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)
|
||||
联合使用，以保证网络策略实施。
|
||||
|
||||
<!--
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) is open source software for
|
||||
providing and transparently securing network connectivity between application
|
||||
containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
|
||||
using an identity based security model that is decoupled from network
|
||||
addressing, and it can be used in combination with other CNI plugins.
|
||||
-->
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) 是一个开源软件，用于提供并透明保护应用容器间的网络连接。
|
||||
Cilium 支持 L7/HTTP，可以在 L3-L7 上通过使用与网络分离的基于身份的安全模型寻址来实施网络策略，
|
||||
并且可以与其他 CNI 插件结合使用。
|
||||
|
||||
<!--
|
||||
### CNI-Genie from Huawei
|
||||
|
||||
[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).
|
||||
|
||||
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
|
||||
-->
|
||||
### 华为的 CNI-Genie {#cni-genie-from-huawei}
|
||||
|
||||
[CNI-Genie](https://github.com/cni-genie/CNI-Genie) 是一个 CNI 插件，
|
||||
可以让 Kubernetes 在运行时使用不同的[网络模型](#the-kubernetes-network-model)的
|
||||
[实现同时被访问](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。
|
||||
这包括以
|
||||
[CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如
|
||||
[Flannel](https://github.com/flannel-io/flannel#flannel)、
|
||||
[Calico](https://projectcalico.docs.tigera.io/about/about-calico/)、
|
||||
[Weave-net](https://www.weave.works/oss/net/)。
|
||||
|
||||
CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)，
|
||||
每个都来自不同的 CNI 插件。
|
||||
|
||||
<!--
|
||||
### cni-ipvlan-vpc-k8s
|
||||
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
|
||||
of CNI and IPAM plugins to provide a simple, host-local, low latency, high
|
||||
throughput, and compliant networking stack for Kubernetes within Amazon Virtual
|
||||
Private Cloud (VPC) environments by making use of Amazon Elastic Network
|
||||
Interfaces (ENI) and binding AWS-managed IPs into Pods using the Linux kernel's
|
||||
IPvlan driver in L2 mode.
|
||||
|
||||
The plugins are designed to be straightforward to configure and deploy within a
|
||||
VPC. Kubelets boot and then self-configure and scale their IP usage as needed
|
||||
without requiring the often recommended complexities of administering overlay
|
||||
networks, BGP, disabling source/destination checks, or adjusting VPC route
|
||||
tables to provide per-instance subnets to each host (which is limited to 50-100
|
||||
entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
|
||||
network complexity required to deploy Kubernetes at scale within AWS.
|
||||
-->
|
||||
### cni-ipvlan-vpc-k8s
|
||||
|
||||
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)
|
||||
包含了一组 CNI 和 IPAM 插件来提供一个简单的、本地主机、低延迟、高吞吐量
|
||||
以及通过使用 Amazon 弹性网络接口（ENI）并使用 Linux 内核的 IPv2 驱动程序
|
||||
以 L2 模式将 AWS 管理的 IP 绑定到 Pod 中，
|
||||
在 Amazon Virtual Private Cloud（VPC）环境中为 Kubernetes 兼容的网络堆栈。
|
||||
|
||||
这些插件旨在直接在 VPC 中进行配置和部署，Kubelets 先启动，
|
||||
然后根据需要进行自我配置和扩展它们的 IP 使用率，而无需经常建议复杂的管理
|
||||
覆盖网络、BGP、禁用源/目标检查或调整 VPC 路由表以向每个主机提供每个实例子网的
|
||||
复杂性（每个 VPC 限制为50-100个条目）。
|
||||
简而言之，cni-ipvlan-vpc-k8s 大大降低了在 AWS 中大规模部署 Kubernetes 所需的网络复杂性。
|
||||
|
||||
<!--
|
||||
### Coil
|
||||
|
||||
[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
|
||||
Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
|
||||
|
||||
-->
|
||||
### Coil
|
||||
|
||||
[Coil](https://github.com/cybozu-go/coil) 是一个为易于集成、提供灵活的出站流量网络而设计的 CNI 插件。
|
||||
与裸机相比，Coil 的额外操作开销低，并允许针对外部网络的出站流量任意定义 NAT 网关。
|
||||
|
||||
<!--
|
||||
### Contiv-VPP
|
||||
|
||||
[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
|
||||
Kubernetes, using the [fd.io](https://fd.io/) data plane.
|
||||
-->
|
||||
### Contiv-VPP
|
||||
[Contiv-VPP](https://contivpp.io/) 是用于 Kubernetes 的用户空间、面向性能的网络插件，使用 [fd.io](https://fd.io/) 数据平面。
|
||||
|
||||
### Contrail / Tungsten Fabric
|
||||
|
||||
<!--
|
||||
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
-->
|
||||
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)
|
||||
是基于 [Tungsten Fabric](https://tungsten.io) 的，真正开放的多云网络虚拟化和策略管理平台。
|
||||
Contrail 和 Tungsten Fabric 与各种编排系统集成在一起，例如 Kubernetes、OpenShift、OpenStack 和 Mesos，
|
||||
并为虚拟机、容器或 Pods 以及裸机工作负载提供了不同的隔离模式。
|
||||
|
||||
<!--
|
||||
### DANM
|
||||
|
||||
[DANM](https://github.com/nokia/danm) is a networking solution for telco workloads running in a Kubernetes cluster. It's built up from the following components:
|
||||
|
||||
* A CNI plugin capable of provisioning IPVLAN interfaces with advanced features
|
||||
* An in-built IPAM module with the capability of managing multiple, cluster-wide, discontinuous L3 networks and provide a dynamic, static, or no IP allocation scheme on-demand
|
||||
* A CNI metaplugin capable of attaching multiple network interfaces to a container, either through its own CNI, or through delegating the job to any of the popular CNI solution like SRI-OV, or Flannel in parallel
|
||||
* A Kubernetes controller capable of centrally managing both VxLAN and VLAN interfaces of all Kubernetes hosts
|
||||
* Another Kubernetes controller extending Kubernetes' Service-based service discovery concept to work over all network interfaces of a Pod
|
||||
|
||||
With this toolset DANM is able to provide multiple separated network interfaces, the possibility to use different networking back ends and advanced IPAM features for the pods.
|
||||
-->
|
||||
### DANM
|
||||
|
||||
[DANM](https://github.com/nokia/danm) 是一个针对在 Kubernetes 集群中运行的电信工作负载的网络解决方案。
|
||||
它由以下几个组件构成：
|
||||
|
||||
* 能够配置具有高级功能的 IPVLAN 接口的 CNI 插件
|
||||
* 一个内置的 IPAM 模块，能够管理多个、集群内的、不连续的 L3 网络，并按请求提供动态、静态或无 IP 分配方案
|
||||
* CNI 元插件能够通过自己的 CNI 或通过将任务授权给其他任何流行的 CNI 解决方案（例如 SRI-OV 或 Flannel）来实现将多个网络接口连接到容器
|
||||
* Kubernetes 控制器能够集中管理所有 Kubernetes 主机的 VxLAN 和 VLAN 接口
|
||||
* 另一个 Kubernetes 控制器扩展了 Kubernetes 的基于服务的服务发现概念，以在 Pod 的所有网络接口上工作
|
||||
|
||||
通过这个工具集，DANM 可以提供多个分离的网络接口，可以为 Pod 使用不同的网络后端和高级 IPAM 功能。
|
||||
|
||||
<!--
|
||||
### Flannel
|
||||
|
||||
[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
|
||||
network that satisfies the Kubernetes requirements. Many
|
||||
people have reported success with Flannel and Kubernetes.
|
||||
-->
|
||||
### Flannel
|
||||
|
||||
[Flannel](https://github.com/flannel-io/flannel#flannel) 是一个非常简单的能够满足
|
||||
Kubernetes 所需要的覆盖网络。已经有许多人报告了使用 Flannel 和 Kubernetes 的成功案例。
|
||||
|
||||
<!--
|
||||
### Hybridnet
|
||||
|
||||
[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity.
|
||||
-->
|
||||
### Hybridnet
|
||||
|
||||
[Hybridnet](https://github.com/alibaba/hybridnet) 是一个为混合云设计的开源 CNI 插件，
|
||||
它为一个或多个集群中的容器提供覆盖和底层网络。Overlay 和 underlay 容器可以在同一个节点上运行，
|
||||
并具有集群范围的双向网络连接。
|
||||
|
||||
<!--
|
||||
### Jaguar
|
||||
|
||||
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
|
||||
|
||||
### k-vswitch
|
||||
|
||||
[k-vswitch](https://github.com/k-vswitch/k-vswitch) is a simple Kubernetes networking plugin based on [Open vSwitch](https://www.openvswitch.org/). It leverages existing functionality in Open vSwitch to provide a robust networking plugin that is easy-to-operate, performant and secure.
|
||||
-->
|
||||
### Jaguar
|
||||
|
||||
[Jaguar](https://gitlab.com/sdnlab/jaguar) 是一个基于 OpenDaylight 的 Kubernetes 网络开源解决方案。
|
||||
Jaguar 使用 vxlan 提供覆盖网络，而 Jaguar CNIPlugin 为每个 Pod 提供一个 IP 地址。
|
||||
|
||||
### k-vswitch
|
||||
|
||||
[k-vswitch](https://github.com/k-vswitch/k-vswitch) 是一个基于
|
||||
[Open vSwitch](https://www.openvswitch.org/) 的简易 Kubernetes 网络插件。
|
||||
它利用 Open vSwitch 中现有的功能来提供强大的网络插件，该插件易于操作，高效且安全。
|
||||
|
||||
<!--
|
||||
### Knitter
|
||||
|
||||
[Knitter](https://github.com/ZTE/Knitter/) is a network solution which supports multiple networking in Kubernetes. It provides the ability of tenant management and network management. Knitter includes a set of end-to-end NFV container networking solutions besides multiple network planes, such as keeping IP address for applications, IP address migration, etc.
|
||||
|
||||
### Kube-OVN
|
||||
|
||||
[Kube-OVN](https://github.com/alauda/kube-ovn) is an OVN-based kubernetes network fabric for enterprises. With the help of OVN/OVS, it provides some advanced overlay network features like subnet, QoS, static IP allocation, traffic mirroring, gateway, openflow-based network policy and service proxy.
|
||||
-->
|
||||
### Knitter
|
||||
|
||||
[Knitter](https://github.com/ZTE/Knitter/) 是一个支持 Kubernetes 中实现多个网络系统的解决方案。
|
||||
它提供了租户管理和网络管理的功能。除了多个网络平面外，Knitter 还包括一组端到端的 NFV 容器网络解决方案，
|
||||
例如为应用程序保留 IP 地址、IP 地址迁移等。
|
||||
|
||||
### Kube-OVN
|
||||
|
||||
[Kube-OVN](https://github.com/alauda/kube-ovn) 是一个基于 OVN 的用于企业的 Kubernetes 网络架构。
|
||||
借助于 OVN/OVS，它提供了一些高级覆盖网络功能，例如子网、QoS、静态 IP 分配、流量镜像、网关、
|
||||
基于 openflow 的网络策略和服务代理。
|
||||
|
||||
<!--
|
||||
### Kube-router
|
||||
|
||||
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
|
||||
-->
|
||||
### Kube-router
|
||||
|
||||
[Kube-router](https://github.com/cloudnativelabs/kube-router) 是 Kubernetes 的专用网络解决方案，
|
||||
旨在提供高性能和易操作性。
|
||||
Kube-router 提供了一个基于 Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)
|
||||
的服务代理、一个基于 Linux 内核转发的无覆盖 Pod-to-Pod 网络解决方案和基于 iptables/ipset 的网络策略执行器。
|
||||
|
||||
<!--
|
||||
### L2 networks and linux bridging
|
||||
|
||||
If you have a "dumb" L2 network, such as a simple switch in a "bare-metal"
|
||||
environment, you should be able to do something similar to the above GCE setup.
|
||||
Note that these instructions have only been tried very casually - it seems to
|
||||
work, but has not been thoroughly tested. If you use this technique and
|
||||
perfect the process, please let us know.
|
||||
|
||||
Follow the "With Linux Bridge devices" section of
|
||||
[this very nice tutorial](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
|
||||
Lars Kellogg-Stedman.
|
||||
-->
|
||||
### L2 networks and linux bridging
|
||||
|
||||
如果你具有一个“哑”的 L2 网络，例如“裸机”环境中的简单交换机，则应该能够执行与上述 GCE 设置类似的操作。
|
||||
请注意，这些说明仅是非常简单的尝试过-似乎可行，但尚未经过全面测试。
|
||||
如果你使用此技术并完善了流程，请告诉我们。
|
||||
|
||||
根据 Lars Kellogg-Stedman 的这份非常不错的 “Linux 网桥设备”
|
||||
[使用说明](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)来进行操作。
|
||||
|
||||
<!--
|
||||
### Multus (a Multi Network plugin)
|
||||
|
||||
Multus is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
|
||||
|
||||
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
|
||||
-->
|
||||
### Multus (a Multi Network plugin)
|
||||
|
||||
[Multus](https://github.com/Intel-Corp/multus-cni) 是一个多 CNI 插件，
|
||||
使用 Kubernetes 中基于 CRD 的网络对象来支持实现 Kubernetes 多网络系统。
|
||||
|
||||
Multus 支持所有[参考插件](https://github.com/containernetworking/plugins)（比如：
|
||||
[Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md)、
|
||||
[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp)、
|
||||
[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan) ）
|
||||
来实现 CNI 规范和第三方插件（比如：
|
||||
[Calico](https://github.com/projectcalico/cni-plugin)、
|
||||
[Weave](https://github.com/weaveworks/weave)、
|
||||
[Cilium](https://github.com/cilium/cilium)、
|
||||
[Contiv](https://github.com/contiv/netplugin)）。
|
||||
除此之外，Multus 还支持
|
||||
[SRIOV](https://github.com/hustcat/sriov-cni)、
|
||||
[DPDK](https://github.com/Intel-Corp/sriov-cni)、
|
||||
[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) 的工作负载，
|
||||
以及 Kubernetes 中基于云的本机应用程序和基于 NFV 的应用程序。
|
||||
|
||||
<!--
|
||||
### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
|
||||
|
||||
[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
-->
|
||||
### OVN4NFV-K8s-Plugin（基于 OVN 的 CNI 控制器和插件） {#ovn4nfv-k8s-plugin-ovn-based-cni-controller-plugin}
|
||||
|
||||
[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是基于 OVN 的
|
||||
CNI 控制器插件，提供基于云原生的服务功能链 (SFC)、多个 OVN
|
||||
覆盖网络、动态子网创建、虚拟网络的动态创建、VLAN Provider 网络、Direct Provider
|
||||
网络且可与其他多网络插件组合，非常适合多集群网络中基于边缘的云原生工作负载。
|
||||
|
||||
<!--
|
||||
### NSX-T
|
||||
|
||||
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
|
||||
|
||||
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
-->
|
||||
### NSX-T
|
||||
|
||||
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) 是一个网络虚拟化和安全平台。
|
||||
NSX-T 可以为多云及多系统管理程序环境提供网络虚拟化，并专注于具有异构端点和技术堆栈的新兴应用程序框架和体系结构。
|
||||
除了 vSphere 管理程序之外，这些环境还包括其他虚拟机管理程序，例如 KVM、容器和裸机。
|
||||
|
||||
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)
|
||||
提供了 NSX-T 与容器协调器（例如 Kubernetes）之间的结合，
|
||||
以及 NSX-T 与基于容器的 CaaS/PaaS 平台（例如 Pivotal Container Service（PKS）和 OpenShift）之间的集成。
|
||||
|
||||
<!--
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN is an opensource network virtualization solution developed by the
|
||||
Open vSwitch community. It lets one create logical switches, logical routers,
|
||||
stateful ACLs, load-balancers etc to build different virtual networking
|
||||
topologies. The project has a specific Kubernetes plugin and documentation
|
||||
at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
-->
|
||||
### OVN（开放式虚拟网络） {#ovn-open-virtual-networking}
|
||||
|
||||
OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。
|
||||
它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。
|
||||
该项目在 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)
|
||||
提供特定的 Kubernetes 插件和文档。
|
||||
|
||||
<!--
|
||||
### Weave Net from Weaveworks
|
||||
|
||||
[Weave Net](https://www.weave.works/oss/net/) is a
|
||||
resilient and simple to use network for Kubernetes and its hosted applications.
|
||||
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
|
||||
or stand-alone. In either version, it doesn't require any configuration or extra code
|
||||
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
|
||||
-->
|
||||
### Weaveworks 的 Weave Net {#weave-net-from-weaveworks}
|
||||
|
||||
[Weave Net](https://www.weave.works/oss/net/) 为 Kubernetes
|
||||
及其托管应用提供的、弹性且易用的网络系统。
|
||||
Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni-plugin/) 运行或者独立运行。
|
||||
在这两种运行方式里，都不需要任何配置或额外的代码即可运行，并且在两种情况下，
|
||||
网络都为每个 Pod 提供一个 IP 地址 -- 这是 Kubernetes 的标准配置。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
The early design of the networking model and its rationale, and some future
|
||||
plans are described in more detail in the
|
||||
[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
-->
|
||||
网络模型的早期设计、运行原理以及未来的一些计划，
|
||||
都在[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)里有更详细的描述。
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
title: Kubernetes 中的代理
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
<!--
|
||||
title: Proxies in Kubernetes
|
||||
content_type: concept
|
||||
weight: 90
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page explains proxies used with Kubernetes.
|
||||
-->
|
||||
本文讲述了 Kubernetes 中所使用的代理。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Proxies
|
||||
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
-->
|
||||
## 代理 {#proxies}
|
||||
|
||||
用户在使用 Kubernetes 的过程中可能遇到几种不同的代理（proxy）：
|
||||
|
||||
<!--
|
||||
1. The [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
|
||||
|
||||
- runs on a user's desktop or in a pod
|
||||
- proxies from a localhost address to the Kubernetes apiserver
|
||||
- client to proxy uses HTTP
|
||||
- proxy to apiserver uses HTTPS
|
||||
- locates apiserver
|
||||
- adds authentication headers
|
||||
-->
|
||||
1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)：
|
||||
|
||||
- 运行在用户的桌面或 pod 中
|
||||
- 从本机地址到 Kubernetes apiserver 的代理
|
||||
- 客户端到代理使用 HTTP 协议
|
||||
- 代理到 apiserver 使用 HTTPS 协议
|
||||
- 指向 apiserver
|
||||
- 添加认证头信息
|
||||
|
||||
<!--
|
||||
1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
|
||||
|
||||
- is a bastion built into the apiserver
|
||||
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
|
||||
- runs in the apiserver processes
|
||||
- client to proxy uses HTTPS (or http if apiserver so configured)
|
||||
- proxy to target may use HTTP or HTTPS as chosen by proxy using available information
|
||||
- can be used to reach a Node, Pod, or Service
|
||||
- does load balancing when used to reach a Service
|
||||
-->
|
||||
2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：
|
||||
|
||||
- 是一个建立在 apiserver 内部的“堡垒”
|
||||
- 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的
|
||||
- 运行在 apiserver 进程内
|
||||
- 客户端到代理使用 HTTPS 协议 (如果配置 apiserver 使用 HTTP 协议，则使用 HTTP 协议)
|
||||
- 通过可用信息进行选择，代理到目的地可能使用 HTTP 或 HTTPS 协议
|
||||
- 可以用来访问 Node、 Pod 或 Service
|
||||
- 当用来访问 Service 时，会进行负载均衡
|
||||
|
||||
<!--
|
||||
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
- runs on each node
|
||||
- proxies UDP, TCP and SCTP
|
||||
- does not understand HTTP
|
||||
- provides load balancing
|
||||
- is only used to reach services
|
||||
-->
|
||||
3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)：
|
||||
|
||||
- 在每个节点上运行
|
||||
- 代理 UDP、TCP 和 SCTP
|
||||
- 不支持 HTTP
|
||||
- 提供负载均衡能力
|
||||
- 只用来访问 Service
|
||||
|
||||
<!--
|
||||
1. A Proxy/Load-balancer in front of apiserver(s):
|
||||
|
||||
- existence and implementation varies from cluster to cluster (e.g. nginx)
|
||||
- sits between all clients and one or more apiservers
|
||||
- acts as load balancer if there are several apiservers.
|
||||
-->
|
||||
4. apiserver 之前的代理/负载均衡器：
|
||||
|
||||
- 在不同集群中的存在形式和实现不同 (如 nginx)
|
||||
- 位于所有客户端和一个或多个 API 服务器之间
|
||||
- 存在多个 API 服务器时，扮演负载均衡器的角色
|
||||
|
||||
<!--
|
||||
1. Cloud Load Balancers on external services:
|
||||
|
||||
- are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
|
||||
- are created automatically when the Kubernetes service has type `LoadBalancer`
|
||||
- usually supports UDP/TCP only
|
||||
- SCTP support is up to the load balancer implementation of the cloud provider
|
||||
- implementation varies by cloud provider.
|
||||
-->
|
||||
5. 外部服务的云负载均衡器：
|
||||
|
||||
- 由一些云供应商提供 (如 AWS ELB、Google Cloud Load Balancer)
|
||||
- Kubernetes 服务类型为 `LoadBalancer` 时自动创建
|
||||
- 通常仅支持 UDP/TCP 协议
|
||||
- SCTP 支持取决于云供应商的负载均衡器实现
|
||||
- 不同云供应商的云负载均衡器实现不同
|
||||
|
||||
<!--
|
||||
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
|
||||
will typically ensure that the latter types are setup correctly.
|
||||
-->
|
||||
|
||||
Kubernetes 用户通常只需要关心前两种类型的代理，集群管理员通常需要确保后面几种类型的代理设置正确。
|
||||
|
||||
<!--
|
||||
## Requesting redirects
|
||||
|
||||
Proxies have replaced redirect capabilities. Redirects have been deprecated.
|
||||
-->
|
||||
## 请求重定向
|
||||
|
||||
代理已经取代重定向功能，重定向功能已被弃用。
|
||||
|
||||
@@ -0,0 +1,396 @@
|
||||
---
|
||||
title: 系统日志
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- dims
|
||||
- 44past4
|
||||
title: System Logs
|
||||
content_type: concept
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
System component logs record events happening in cluster, which can be very useful for debugging.
|
||||
You can configure log verbosity to see more or less detail.
|
||||
Logs can be as coarse-grained as showing errors within a component, or as fine-grained as showing step-by-step traces of events (like HTTP access logs, pod state changes, controller actions, or scheduler decisions).
|
||||
-->
|
||||
系统组件的日志记录集群中发生的事件，这对于调试非常有用。
|
||||
你可以配置日志的精细度，以展示更多或更少的细节。
|
||||
日志可以是粗粒度的，如只显示组件内的错误，
|
||||
也可以是细粒度的，如显示事件的每一个跟踪步骤（比如 HTTP 访问日志、pod 状态更新、控制器动作或调度器决策）。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Klog
|
||||
|
||||
<!--
|
||||
klog is the Kubernetes logging library. [klog](https://github.com/kubernetes/klog)
|
||||
generates log messages for the Kubernetes system components.
|
||||
|
||||
For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
|
||||
-->
|
||||
klog 是 Kubernetes 的日志库。
|
||||
[klog](https://github.com/kubernetes/klog)
|
||||
为 Kubernetes 系统组件生成日志消息。
|
||||
|
||||
有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
|
||||
|
||||
<!--
|
||||
Kubernetes is in the process of simplifying logging in its components. The
|
||||
following klog command line flags [are
|
||||
deprecated](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
|
||||
starting with Kubernetes 1.23 and will be removed in a future release:
|
||||
-->
|
||||
Kubernetes 正在进行简化其组件日志的努力。下面的 klog 命令行参数从 Kubernetes 1.23
|
||||
开始[已被废弃](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)，
|
||||
会在未来版本中移除：
|
||||
|
||||
- `--add-dir-header`
|
||||
- `--alsologtostderr`
|
||||
- `--log-backtrace-at`
|
||||
- `--log-dir`
|
||||
- `--log-file`
|
||||
- `--log-file-max-size`
|
||||
- `--logtostderr`
|
||||
- `--one-output`
|
||||
- `--skip-headers`
|
||||
- `--skip-log-headers`
|
||||
- `--stderrthreshold`
|
||||
|
||||
<!--
|
||||
Output will always be written to stderr, regardless of the output
|
||||
format. Output redirection is expected to be handled by the component which
|
||||
invokes a Kubernetes component. This can be a POSIX shell or a tool like
|
||||
systemd.
|
||||
-->
|
||||
输出总会被写到标准错误输出（stderr）之上，无论输出格式如何。
|
||||
对输出的重定向将由调用 Kubernetes 组件的软件来处理。
|
||||
这一软件可以是 POSIX Shell 或者类似 systemd 这样的工具。
|
||||
|
||||
<!--
|
||||
In some cases, for example a distroless container or a Windows system service,
|
||||
those options are not available. Then the
|
||||
[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
|
||||
binary can be used as wrapper around a Kubernetes component to redirect
|
||||
output. A prebuilt binary is included in several Kubernetes base images under
|
||||
its traditional name as `/go-runner` and as `kube-log-runner` in server and
|
||||
node release archives.
|
||||
-->
|
||||
在某些场合下，例如对于无发行主体的（distroless）容器或者 Windows 系统服务，
|
||||
这些替代方案都是不存在的。那么你可以使用
|
||||
[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
|
||||
可执行文件来作为 Kubernetes 的封装层，完成对输出的重定向。
|
||||
在很多 Kubernetes 基础镜像中，都包含一个预先构建的可执行程序。
|
||||
这个程序原来称作 `/go-runner`，而在服务器和节点的发行版本库中，称作 `kube-log-runner`。
|
||||
|
||||
<!--
|
||||
This table shows how `kube-log-runner` invocations correspond to shell redirection:
|
||||
-->
|
||||
下表展示的是 `kube-log-runner` 调用与 Shell 重定向之间的对应关系：
|
||||
|
||||
<!--
|
||||
| Usage | POSIX shell (such as bash) | `kube-log-runner <options> <cmd>` |
|
||||
| -----------------------------------------|----------------------------|-------------------------------------------------------------|
|
||||
| Merge stderr and stdout, write to stdout | `2>&1` | `kube-log-runner` (default behavior) |
|
||||
| Redirect both into log file | `1>>/tmp/log 2>&1` | `kube-log-runner -log-file=/tmp/log` |
|
||||
| Copy into log file and to stdout | `2>&1 \| tee -a /tmp/log` | `kube-log-runner -log-file=/tmp/log -also-stdout` |
|
||||
| Redirect only stdout into log file | `>/tmp/log` | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
|
||||
-->
|
||||
| 用法 | POSIX Shell（例如 Bash） | `kube-log-runner <options> <cmd>` |
|
||||
| --------------------------------|--------------------------|------------------------------------|
|
||||
| 合并 stderr 与 stdout，写出到 stdout | `2>&1` | `kube-log-runner`（默认行为 ）|
|
||||
| 将 stderr 与 stdout 重定向到日志文件 | `1>>/tmp/log 2>&1` | `kube-log-runner -log-file=/tmp/log` |
|
||||
| 输出到 stdout 并复制到日志文件中 | `2>&1 \| tee -a /tmp/log` | `kube-log-runner -log-file=/tmp/log -also-stdout` |
|
||||
| 仅将 stdout 重定向到日志 | `>/tmp/log` | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
|
||||
|
||||
<!--
|
||||
### Klog output
|
||||
|
||||
An example of the traditional klog native format:
|
||||
-->
|
||||
### klog 输出
|
||||
|
||||
传统的 klog 原生格式示例：
|
||||
|
||||
```
|
||||
I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
|
||||
```
|
||||
|
||||
<!--
|
||||
The message string may contain line breaks:
|
||||
-->
|
||||
消息字符串可能包含换行符：
|
||||
|
||||
```
|
||||
I1025 00:15:15.525108 1 example.go:79] This is a message
|
||||
which has a line break.
|
||||
```
|
||||
|
||||
<!--
|
||||
### Structured Logging
|
||||
-->
|
||||
### 结构化日志
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages.
|
||||
|
||||
Log formatting and value serialization are subject to change.
|
||||
-->
|
||||
迁移到结构化日志消息是一个正在进行的过程。在此版本中，并非所有日志消息都是结构化的。
|
||||
解析日志文件时，你也必须要处理非结构化日志消息。
|
||||
|
||||
日志格式和值的序列化可能会发生变化。
|
||||
{{< /warning>}}
|
||||
|
||||
<!--
|
||||
Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost.
|
||||
The code which generates a log message determines whether it uses the traditional unstructured klog output
|
||||
or structured logging.
|
||||
-->
|
||||
结构化日志记录旨在日志消息中引入统一结构，以便以编程方式提取信息。
|
||||
你可以方便地用更小的开销来处理结构化日志。
|
||||
生成日志消息的代码决定其使用传统的非结构化的 klog 还是结构化的日志。
|
||||
|
||||
<!--
|
||||
The default formatting of structured log messages is as text, with a format that
|
||||
is backward compatible with traditional klog:
|
||||
-->
|
||||
默认的结构化日志消息是以文本形式呈现的，其格式与传统的 klog 保持向后兼容：
|
||||
|
||||
```ini
|
||||
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
|
||||
```
|
||||
|
||||
<!--
|
||||
Example:
|
||||
-->
|
||||
示例：
|
||||
|
||||
```ini
|
||||
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
|
||||
```
|
||||
|
||||
<!--
|
||||
Strings are quoted. Other values are formatted with
|
||||
[`%+v`](https://pkg.go.dev/fmt#hdr-Printing), which may cause log messages to
|
||||
continue on the next line [depending on the data](https://github.com/kubernetes/kubernetes/issues/106428).
|
||||
-->
|
||||
字符串在输出时会被添加引号。其他数值类型都使用 [`%+v`](https://pkg.go.dev/fmt#hdr-Printing)
|
||||
来格式化，因此可能导致日志消息会延续到下一行，
|
||||
[具体取决于数据本身](https://github.com/kubernetes/kubernetes/issues/106428)。
|
||||
|
||||
```
|
||||
I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
|
||||
second line.}
|
||||
```
|
||||
|
||||
<!--
|
||||
### Contextual Logging
|
||||
-->
|
||||
### 上下文日志
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
Contextual logging builds on top of structured logging. It is primarily about
|
||||
how developers use logging calls: code based on that concept is more flexible
|
||||
and supports additional use cases as described in the [Contextual Logging
|
||||
KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging).
|
||||
-->
|
||||
上下文日志建立在结构化日志之上。
|
||||
它主要是关于开发人员如何使用日志记录调用：基于该概念的代码将更加灵活，
|
||||
并且支持在[结构化日志 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)
|
||||
中描述的额外用例。
|
||||
|
||||
<!--
|
||||
If developers use additional functions like `WithValues` or `WithName` in
|
||||
their components, then log entries contain additional information that gets
|
||||
passed into functions by their caller.
|
||||
-->
|
||||
如果开发人员在他们的组件中使用额外的函数，比如 `WithValues` 或 `WithName`，
|
||||
那么日志条目将会包含额外的信息，这些信息会被调用者传递给函数。
|
||||
|
||||
<!--
|
||||
Currently this is gated behind the `StructuredLogging` feature gate and
|
||||
disabled by default. The infrastructure for this was added in 1.24 without
|
||||
modifying components. The
|
||||
[`component-base/logs/example`](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go)
|
||||
command demonstrates how to use the new logging calls and how a component
|
||||
behaves that supports contextual logging.
|
||||
-->
|
||||
目前这一特性是由 `StructuredLogging` 特性门控所控制的，默认关闭。
|
||||
这个基础设施是在 1.24 中被添加的，并不需要修改组件。
|
||||
该 [`component-base/logs/example`](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go)
|
||||
命令演示了如何使用新的日志记录调用以及组件如何支持上下文日志记录。
|
||||
|
||||
```console
|
||||
$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
|
||||
$ go run . --help
|
||||
...
|
||||
--feature-gates mapStringBool A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
|
||||
AllAlpha=true|false (ALPHA - default=false)
|
||||
AllBeta=true|false (BETA - default=false)
|
||||
ContextualLogging=true|false (ALPHA - default=false)
|
||||
$ go run . --feature-gates ContextualLogging=true
|
||||
...
|
||||
I0404 18:00:02.916429 451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s"
|
||||
I0404 18:00:02.916447 451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s"
|
||||
```
|
||||
|
||||
<!--
|
||||
The `example` prefix and `foo="bar"` were added by the caller of the function
|
||||
which logs the `runtime` message and `duration="1m0s"` value, without having to
|
||||
modify that function.
|
||||
|
||||
With contextual logging disable, `WithValues` and `WithName` do nothing and log
|
||||
calls go through the global klog logger. Therefore this additional information
|
||||
is not in the log output anymore:
|
||||
-->
|
||||
`example` 前缀和 `foo="bar"` 会被函数的调用者添加上，
|
||||
不需修改该函数，它就会记录 `runtime` 消息和 `duration="1m0s"` 值。
|
||||
|
||||
禁用上下文日志后，`WithValues` 和 `WithName` 什么都不会做，
|
||||
并且会通过调用全局的 klog 日志记录器记录日志。
|
||||
因此，这些附加信息不再出现在日志输出中：
|
||||
|
||||
```console
|
||||
$ go run . --feature-gates ContextualLogging=false
|
||||
...
|
||||
I0404 18:03:31.171945 452150 logger.go:94] "runtime" duration="1m0s"
|
||||
I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s"
|
||||
```
|
||||
|
||||
<!--
|
||||
### JSON log format
|
||||
-->
|
||||
### JSON 日志格式
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
JSON output does not support many standard klog flags. For list of unsupported klog flags, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
|
||||
|
||||
Not all logs are guaranteed to be written in JSON format (for example, during process start). If you intend to parse logs, make sure you can handle log lines that are not JSON as well.
|
||||
|
||||
Field names and JSON serialization are subject to change.
|
||||
-->
|
||||
JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表，
|
||||
请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。
|
||||
|
||||
并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。
|
||||
如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。
|
||||
|
||||
字段名和 JSON 序列化可能会发生变化。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
The `--logging-format=json` flag changes the format of logs from klog native format to JSON format.
|
||||
Example of JSON log format (pretty printed):
|
||||
-->
|
||||
`--logging-format=json` 参数将日志格式从 klog 原生格式改为 JSON 格式。
|
||||
JSON 日志格式示例（美化输出）：
|
||||
```json
|
||||
{
|
||||
"ts": 1580306777.04728,
|
||||
"v": 4,
|
||||
"msg": "Pod status updated",
|
||||
"pod":{
|
||||
"name": "nginx-1",
|
||||
"namespace": "default"
|
||||
},
|
||||
"status": "ready"
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
Keys with special meaning:
|
||||
|
||||
* `ts` - timestamp as Unix time (required, float)
|
||||
* `v` - verbosity (only for info and not for error messages, int)
|
||||
* `err` - error string (optional, string)
|
||||
* `msg` - message (required, string)
|
||||
|
||||
List of components currently supporting JSON format:
|
||||
-->
|
||||
具有特殊意义的 key：
|
||||
* `ts` - Unix 时间风格的时间戳（必选项，浮点值）
|
||||
* `v` - 精细度（仅用于 info 级别，不能用于错误信息，整数）
|
||||
* `err` - 错误字符串（可选项，字符串）
|
||||
* `msg` - 消息（必选项，字符串）
|
||||
|
||||
当前支持JSON格式的组件列表：
|
||||
|
||||
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
|
||||
|
||||
<!--
|
||||
### Log verbosity level
|
||||
|
||||
The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events.
|
||||
Increasing verbosity settings logs increasingly less severe events. A verbosity setting of 0 logs only critical events.
|
||||
-->
|
||||
### 日志精细度级别
|
||||
|
||||
参数 `-v` 控制日志的精细度。增大该值会增大日志事件的数量。
|
||||
减小该值可以减小日志事件的数量。增大精细度会记录更多的不太严重的事件。
|
||||
精细度设置为 0 时只记录关键（critical）事件。
|
||||
|
||||
<!--
|
||||
### Log location
|
||||
|
||||
There are two types of system components: those that run in a container and those
|
||||
that do not run in a container. For example:
|
||||
|
||||
* The Kubernetes scheduler and kube-proxy run in a container.
|
||||
* The kubelet and {{<glossary_tooltip term_id="container-runtime" text="container runtime">}}
|
||||
do not run in containers.
|
||||
-->
|
||||
### 日志位置
|
||||
|
||||
有两种类型的系统组件：运行在容器中的组件和不运行在容器中的组件。例如：
|
||||
|
||||
* Kubernetes 调度器和 kube-proxy 在容器中运行。
|
||||
* kubelet 和{{<glossary_tooltip term_id="container-runtime" text="容器运行时">}}不在容器中运行。
|
||||
|
||||
<!--
|
||||
On machines with systemd, the kubelet and container runtime write to journald.
|
||||
Otherwise, they write to `.log` files in the `/var/log` directory.
|
||||
System components inside containers always write to `.log` files in the `/var/log` directory,
|
||||
bypassing the default logging mechanism.
|
||||
Similar to the container logs, you should rotate system component logs in the `/var/log` directory.
|
||||
In Kubernetes clusters created by the `kube-up.sh` script, log rotation is configured by the `logrotate` tool.
|
||||
The `logrotate` tool rotates logs daily, or once the log size is greater than 100MB.
|
||||
-->
|
||||
在使用 systemd 的系统中，kubelet 和容器运行时写入 journald。
|
||||
在别的系统中，日志写入 `/var/log` 目录下的 `.log` 文件中。
|
||||
容器中的系统组件总是绕过默认的日志记录机制，写入 `/var/log` 目录下的 `.log` 文件。
|
||||
与容器日志类似，你应该轮转 `/var/log` 目录下系统组件日志。
|
||||
在 `kube-up.sh` 脚本创建的 Kubernetes 集群中，日志轮转由 `logrotate` 工具配置。
|
||||
`logrotate` 工具，每天或者当日志大于 100MB 时，轮转日志。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read about the [Kubernetes Logging Architecture](/docs/concepts/cluster-administration/logging/)
|
||||
* Read about [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
|
||||
* Read about [Contextual Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)
|
||||
* Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
|
||||
* Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
|
||||
-->
|
||||
* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/)
|
||||
* 阅读[结构化日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
|
||||
* 阅读[上下文日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)
|
||||
* 阅读 [klog 参数的废弃（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
|
||||
* 阅读[日志严重级别约定（英文）](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
|
||||
|
||||
@@ -0,0 +1,344 @@
|
||||
---
|
||||
title: Kubernetes 系统组件指标
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Metrics For Kubernetes System Components
|
||||
reviewers:
|
||||
- brancz
|
||||
- logicalhan
|
||||
- RainbowMango
|
||||
content_type: concept
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
|
||||
|
||||
Kubernetes components emit metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/).
|
||||
This format is structured plain text, designed so that people and machines can both read it.
|
||||
-->
|
||||
通过系统组件指标可以更好地了解系统组个内部发生的情况。系统组件指标对于构建仪表板和告警特别有用。
|
||||
|
||||
Kubernetes 组件以 [Prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/)
|
||||
生成度量值。
|
||||
这种格式是结构化的纯文本，旨在使人和机器都可以阅读。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## 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.
|
||||
|
||||
Examples of those components:
|
||||
-->
|
||||
## Kubernetes 中组件的指标
|
||||
|
||||
在大多数情况下，可以通过 HTTP 访问组件的 `/metrics` 端点来获取组件的度量值。
|
||||
对于那些默认情况下不暴露端点的组件，可以使用 `--bind-address` 标志启用。
|
||||
|
||||
这些组件的示例：
|
||||
|
||||
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
|
||||
|
||||
<!--
|
||||
In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
|
||||
to periodically gather these metrics and make them available in some kind of time series database.
|
||||
|
||||
Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
|
||||
|
||||
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/) 或
|
||||
某些其他指标搜集器以定期收集这些指标，并使它们在某种时间序列数据库中可用。
|
||||
|
||||
请注意，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 还会在 `/metrics/cadvisor`，
|
||||
`/metrics/resource` 和 `/metrics/probes` 端点中公开度量值。这些度量值的生命周期各不相同。
|
||||
|
||||
如果你的集群使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}，
|
||||
则读取指标需要通过基于用户、组或 ServiceAccount 的鉴权，要求具有允许访问
|
||||
`/metrics` 的 ClusterRole。
|
||||
例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: prometheus
|
||||
rules:
|
||||
- nonResourceURLs:
|
||||
- "/metrics"
|
||||
verbs:
|
||||
- get
|
||||
```
|
||||
|
||||
<!--
|
||||
## Metric lifecycle
|
||||
|
||||
Alpha metric → Stable metric → Deprecated metric → Hidden metric → Deleted metric
|
||||
|
||||
Alpha metrics have no stability guarantees. These metrics can be modified or deleted at any time.
|
||||
|
||||
Stable metrics are guaranteed to not change. This means:
|
||||
* A stable metric without a deprecated signature will not be deleted or renamed
|
||||
* A stable metric's type will not be modified
|
||||
|
||||
Deprecated metrics are slated for deletion, but are still available for use.
|
||||
These metrics include an annotation about the version in which they became deprecated.
|
||||
-->
|
||||
## 指标生命周期
|
||||
|
||||
Alpha 指标 → 稳定的指标 → 弃用的指标 → 隐藏的指标 → 删除的指标
|
||||
|
||||
Alpha 指标没有稳定性保证。这些指标可以随时被修改或者删除。
|
||||
|
||||
稳定的指标可以保证不会改变。这意味着：
|
||||
|
||||
* 稳定的、不包含已弃用（deprecated）签名的指标不会被删除（或重命名）
|
||||
* 稳定的指标的类型不会被更改
|
||||
|
||||
已弃用的指标最终将被删除，不过仍然可用。
|
||||
这类指标包含注解，标明其被废弃的版本。
|
||||
|
||||
<!--
|
||||
For example:
|
||||
|
||||
* Before deprecation
|
||||
-->
|
||||
例如：
|
||||
|
||||
* 被弃用之前：
|
||||
|
||||
```
|
||||
# HELP some_counter this counts things
|
||||
# TYPE some_counter counter
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
<!--
|
||||
* After deprecation
|
||||
-->
|
||||
* 被弃用之后：
|
||||
|
||||
```
|
||||
# HELP some_counter (Deprecated since 1.15.0) this counts things
|
||||
# TYPE some_counter counter
|
||||
some_counter 0
|
||||
```
|
||||
|
||||
<!--
|
||||
Hidden metrics are no longer published for scraping, but are still available for use. To use a hidden metric, please refer to the [Show hidden metrics](#show-hidden-metrics) section.
|
||||
|
||||
Deleted metrics are no longer published and cannot be used.
|
||||
-->
|
||||
隐藏的指标不会再被发布以供抓取，但仍然可用。
|
||||
要使用隐藏指标，请参阅[显式隐藏指标](#show-hidden-metrics)节。
|
||||
|
||||
删除的指标不再被发布，亦无法使用。
|
||||
|
||||
<!--
|
||||
## Show hidden metrics
|
||||
|
||||
As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
|
||||
|
||||
The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
|
||||
|
||||
The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
|
||||
|
||||
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}
|
||||
|
||||
如上所述，管理员可以通过设置可执行文件的命令行参数来启用隐藏指标，
|
||||
如果管理员错过了上一版本中已经弃用的指标的迁移，则可以把这个用作管理员的逃生门。
|
||||
|
||||
`show-hidden-metrics-for-version` 标志接受版本号作为取值，版本号给出
|
||||
你希望显示该发行版本中已弃用的指标。
|
||||
版本表示为 x.y，其中 x 是主要版本，y 是次要版本。补丁程序版本不是必须的，
|
||||
即使指标可能会在补丁程序发行版中弃用，原因是指标弃用策略规定仅针对次要版本。
|
||||
|
||||
该参数只能使用前一个次要版本。如果管理员将先前版本设置为 `show-hidden-metrics-for-version`，
|
||||
则先前版本中隐藏的度量值会再度生成。不允许使用过旧的版本，因为那样会违反指标弃用策略。
|
||||
|
||||
以指标 `A` 为例，此处假设 `A` 在 1.n 中已弃用。根据指标弃用策略，我们可以得出以下结论：
|
||||
|
||||
<!--
|
||||
* In release `1.n`, the metric is deprecated, and it can be emitted by default.
|
||||
* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
|
||||
* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
|
||||
|
||||
If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
|
||||
-->
|
||||
* 在版本 `1.n` 中，这个指标已经弃用，且默认情况下可以生成。
|
||||
* 在版本 `1.n+1` 中，这个指标默认隐藏，可以通过命令行参数 `show-hidden-metrics-for-version=1.n` 来再度生成。
|
||||
* 在版本 `1.n+2` 中，这个指标就将被从代码中移除，不会再有任何逃生窗口。
|
||||
|
||||
如果你要从版本 `1.12` 升级到 `1.13`，但仍依赖于 `1.12` 中弃用的指标 `A`，则应通过命令行设置隐藏指标：
|
||||
`--show-hidden-metrics=1.12`，并记住在升级到 `1.14` 版本之前删除此指标依赖项。
|
||||
|
||||
<!--
|
||||
## Disable accelerator metrics
|
||||
|
||||
The kubelet collects accelerator metrics through cAdvisor. To collect these metrics, for accelerators like NVIDIA GPUs, kubelet held an open handle on the driver. This meant that in order to perform infrastructure changes (for example, updating the driver), a cluster administrator needed to stop the kubelet agent.
|
||||
|
||||
The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
|
||||
|
||||
The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
-->
|
||||
## 禁用加速器指标
|
||||
|
||||
kubelet 通过 cAdvisor 收集加速器指标。为了收集这些指标，对于 NVIDIA GPU 之类的加速器，
|
||||
kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结构更改（例如更新驱动程序），
|
||||
集群管理员需要停止 kubelet 代理。
|
||||
|
||||
现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器，
|
||||
并将其公开给指标服务（例如 Prometheus）。
|
||||
|
||||
[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
禁止由 kubelet 收集的指标。
|
||||
关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
|
||||
|
||||
<!--
|
||||
## Component metrics
|
||||
|
||||
### kube-controller-manager metrics
|
||||
|
||||
Controller manager metrics provide important insight into the performance and health of the controller manager.
|
||||
These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
|
||||
etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
|
||||
to gauge the health of a cluster.
|
||||
|
||||
Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
|
||||
These metrics can be used to monitor health of persistent volume operations.
|
||||
|
||||
For example, for GCE these metrics are called:
|
||||
-->
|
||||
## 组件指标
|
||||
|
||||
### kube-controller-manager 指标
|
||||
|
||||
控制器管理器指标可提供有关控制器管理器性能和运行状况的重要洞察。
|
||||
这些指标包括通用的 Go 语言运行时指标（例如 go_routine 数量）和控制器特定的度量指标，
|
||||
例如可用于评估集群运行状况的 etcd 请求延迟或云提供商（AWS、GCE、OpenStack）的 API 延迟等。
|
||||
|
||||
从 Kubernetes 1.7 版本开始，详细的云提供商指标可用于 GCE、AWS、Vsphere 和 OpenStack 的存储操作。
|
||||
这些指标可用于监控持久卷操作的运行状况。
|
||||
|
||||
比如，对于 GCE，这些指标称为：
|
||||
|
||||
```
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
<!--
|
||||
### kube-scheduler metrics
|
||||
-->
|
||||
### kube-scheduler 指标 {#kube-scheduler-metrics}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
||||
|
||||
<!--
|
||||
The scheduler exposes optional metrics that reports the requested resources and the desired limits of all running pods. These metrics can be used to build capacity planning dashboards, assess current or historical scheduling limits, quickly identify workloads that cannot schedule due to lack of resources, and compare actual usage to the pod's request.
|
||||
-->
|
||||
调度器会暴露一些可选的指标，报告所有运行中 Pods 所请求的资源和期望的约束值。
|
||||
这些指标可用来构造容量规划监控面板、访问调度约束的当前或历史数据、
|
||||
快速发现因为缺少资源而无法被调度的负载，或者将 Pod 的实际资源用量
|
||||
与其请求值进行比较。
|
||||
|
||||
<!--
|
||||
The kube-scheduler identifies the resource [requests and limits](/docs/concepts/configuration/manage-resources-containers/) configured for each Pod; when either a request or limit is non-zero, the kube-scheduler reports a metrics timeseries. The time series is labelled by:
|
||||
- namespace
|
||||
- pod name
|
||||
- the node where the pod is scheduled or an empty string if not yet scheduled
|
||||
- priority
|
||||
- the assigned scheduler for that pod
|
||||
- the name of the resource (for example, `cpu`)
|
||||
- the unit of the resource if known (for example, `cores`)
|
||||
-->
|
||||
kube-scheduler 组件能够辩识各个 Pod 所配置的资源
|
||||
[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。
|
||||
在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式
|
||||
生成报告。该时间序列值包含以下标签：
|
||||
- 名字空间
|
||||
- Pod 名称
|
||||
- Pod 调度所处节点，或者当 Pod 未被调度时用空字符串表示
|
||||
- 优先级
|
||||
- 为 Pod 所指派的调度器
|
||||
- 资源的名称（例如，`cpu`）
|
||||
- 资源的单位，如果知道的话（例如，`cores`）
|
||||
|
||||
<!--
|
||||
Once a pod reaches completion (has a `restartPolicy` of `Never` or `OnFailure` and is in the `Succeeded` or `Failed` pod phase, or has been deleted and all containers have a terminated state) the series is no longer reported since the scheduler is now free to schedule other pods to run. The two metrics are called `kube_pod_resource_request` and `kube_pod_resource_limit`.
|
||||
|
||||
The metrics are exposed at the HTTP endpoint `/metrics/resources` and require the same authorization as the `/metrics`
|
||||
endpoint on the scheduler. You must use the `-show-hidden-metrics-for-version=1.20` flag to expose these alpha stability metrics.
|
||||
-->
|
||||
一旦 Pod 进入完成状态（其 `restartPolicy` 为 `Never` 或 `OnFailure`，且
|
||||
其处于 `Succeeded` 或 `Failed` Pod 阶段，或者已经被删除且所有容器都具有
|
||||
终止状态），该时间序列停止报告，因为调度器现在可以调度其它 Pod 来执行。
|
||||
这两个指标称作 `kube_pod_resource_request` 和 `kube_pod_resource_limit`。
|
||||
|
||||
指标暴露在 HTTP 端点 `/metrics/resources`，与调度器上的 `/metrics` 端点
|
||||
一样要求相同的访问授权。你必须使用
|
||||
`--show-hidden-metrics-for-version=1.20` 标志才能暴露那些稳定性为 Alpha
|
||||
的指标。
|
||||
|
||||
<!--
|
||||
## Disabling metrics
|
||||
|
||||
You can explicitly turn off metrics via command line flag `--disabled-metrics`. This may be desired if, for example, a metric is causing a performance problem. The input is a list of disabled metrics (i.e. `--disabled-metrics=metric1,metric2`).
|
||||
-->
|
||||
## 禁用指标 {#disabling-metrics}
|
||||
|
||||
你可以通过命令行标志 `--disabled-metrics` 来关闭某指标。
|
||||
在例如某指标会带来性能问题的情况下，这一操作可能是有用的。
|
||||
标志的参数值是一组被禁止的指标（例如：`--disabled-metrics=metric1,metric2`）。
|
||||
|
||||
<!--
|
||||
## Metric cardinality enforcement
|
||||
|
||||
Metrics with unbounded dimensions could cause memory issues in the components they instrument. To limit resource use, you can use the `--allow-label-value` command line option to dynamically configure an allow-list of label values for a metric.
|
||||
-->
|
||||
## 指标顺序性保证 {#metric-cardinality-enforcement}
|
||||
|
||||
在 Alpha 阶段，标志只能接受一组映射值作为可以使用的指标标签。
|
||||
每个映射值的格式为`<指标名称>,<标签名称>=<可用标签列表>`，其中
|
||||
`<可用标签列表>` 是一个用逗号分隔的、可接受的标签名的列表。
|
||||
|
||||
<!--
|
||||
The overall format looks like:
|
||||
`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
|
||||
-->
|
||||
最终的格式看起来会是这样：
|
||||
`--allow-label-value <指标名称>,<标签名称>='<可用值1>,<可用值2>...', <指标名称2>,<标签名称>='<可用值1>, <可用值2>...', ...`.
|
||||
|
||||
<!--
|
||||
Here is an example:
|
||||
-->
|
||||
下面是一个例子：
|
||||
|
||||
`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
|
||||
|
||||
## {{% 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
|
||||
* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
-->
|
||||
* 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
|
||||
* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
title: 追踪 Kubernetes 系统组件
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Traces For Kubernetes System Components
|
||||
reviewers:
|
||||
- logicalhan
|
||||
- lilic
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
System component traces record the latency of and relationships between operations in the cluster.
|
||||
-->
|
||||
系统组件追踪功能记录各个集群操作的时延信息和这些操作之间的关系。
|
||||
|
||||
<!--
|
||||
Kubernetes components emit traces using the
|
||||
[OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification)
|
||||
with the gRPC exporter and can be collected and routed to tracing backends using an
|
||||
[OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector).
|
||||
-->
|
||||
Kubernetes 组件基于 gRPC 导出器的
|
||||
[OpenTelemetry 协议](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification)
|
||||
发送追踪信息，并用
|
||||
[OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector)
|
||||
收集追踪信息，再将其转交给追踪系统的后台。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Trace Collection
|
||||
-->
|
||||
## 追踪信息的收集 {#trace-collection}
|
||||
|
||||
<!--
|
||||
For a complete guide to collecting traces and using the collector, see
|
||||
[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/).
|
||||
However, there are a few things to note that are specific to Kubernetes components.
|
||||
-->
|
||||
关于收集追踪信息、以及使用收集器的完整指南，可参见
|
||||
[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)。
|
||||
不过，还有一些特定于 Kubernetes 组件的事项值得注意。
|
||||
|
||||
<!--
|
||||
By default, Kubernetes components export traces using the grpc exporter for OTLP on the
|
||||
[IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317.
|
||||
As an example, if the collector is running as a sidecar to a Kubernetes component,
|
||||
the following receiver configuration will collect spans and log them to standard output:
|
||||
-->
|
||||
默认情况下，Kubernetes 组件使用 gRPC 的 OTLP 导出器来导出追踪信息，将信息写到
|
||||
[IANA OpenTelemetry 端口](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry)。
|
||||
举例来说，如果收集器以 Kubernetes 组件的边车模式运行，以下接收器配置会收集 spans 信息，并将它们写入到标准输出。
|
||||
|
||||
<!--
|
||||
# Replace this exporter with the exporter for your backend
|
||||
-->
|
||||
```yaml
|
||||
receivers:
|
||||
otlp:
|
||||
protocols:
|
||||
grpc:
|
||||
exporters:
|
||||
# 用适合你后端环境的导出器替换此处的导出器
|
||||
logging:
|
||||
logLevel: debug
|
||||
service:
|
||||
pipelines:
|
||||
traces:
|
||||
receivers: [otlp]
|
||||
exporters: [logging]
|
||||
```
|
||||
|
||||
<!--
|
||||
## Component traces
|
||||
|
||||
### kube-apiserver traces
|
||||
-->
|
||||
## 组件追踪 {#component-traces}
|
||||
|
||||
### kube-apiserver 追踪 {#kube-apiserver-traces}
|
||||
|
||||
<!--
|
||||
The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests
|
||||
to webhooks, etcd, and re-entrant requests. It propagates the
|
||||
[W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests
|
||||
but does not make use of the trace context attached to incoming requests,
|
||||
as the kube-apiserver is often a public endpoint.
|
||||
-->
|
||||
kube-apiserver 为传入的 HTTP 请求、传出到 webhook 和 etcd 的请求以及重入的请求生成 spans。
|
||||
由于 kube-apiserver 通常是一个公开的端点，所以它通过出站的请求传播
|
||||
[W3C 追踪上下文](https://www.w3.org/TR/trace-context/)，
|
||||
但不使用入站请求的追踪上下文。
|
||||
|
||||
<!--
|
||||
#### Enabling tracing in the kube-apiserver
|
||||
-->
|
||||
#### 在 kube-apiserver 中启用追踪 {#enabling-tracing-in-the-kube-apiserver}
|
||||
|
||||
<!--
|
||||
To enable tracing, enable the `APIServerTracing`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file
|
||||
with `--tracing-config-file=<path-to-config>`. This is an example config that records
|
||||
spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
|
||||
-->
|
||||
要启用追踪特性，需要启用 kube-apiserver 上的 `APIServerTracing`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。
|
||||
下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1alpha1
|
||||
kind: TracingConfiguration
|
||||
# default value
|
||||
#endpoint: localhost:4317
|
||||
samplingRatePerMillion: 100
|
||||
```
|
||||
|
||||
<!--
|
||||
For more information about the `TracingConfiguration` struct, see
|
||||
[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration).
|
||||
-->
|
||||
|
||||
有关 TracingConfiguration 结构体的更多信息，请参阅
|
||||
[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。
|
||||
|
||||
<!--
|
||||
## Stability
|
||||
-->
|
||||
## 稳定性 {#stability}
|
||||
|
||||
<!--
|
||||
Tracing instrumentation is still under active development, and may change
|
||||
in a variety of ways. This includes span names, attached attributes,
|
||||
instrumented endpoints, etc. Until this feature graduates to stable,
|
||||
there are no guarantees of backwards compatibility for tracing instrumentation.
|
||||
-->
|
||||
追踪工具仍在积极开发中，未来它会以多种方式发生变化。
|
||||
这些变化包括：span 名称、附加属性、检测端点等等。
|
||||
此类特性在达到稳定版本之前，不能保证追踪工具的向后兼容性。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
|
||||
-->
|
||||
* 阅读[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
|
||||
Reference in New Issue
Block a user