Merge pull request #27797 from tengqm/zh-sync-concepts-15
[zh] Resync concepts section (15)pull/27983/head
Kubernetes Prow Robot
GitHub
commit
b2245f8f34
|
|
@ -25,8 +25,8 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
<!--
|
||||
## 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.
|
||||
|
|
@ -46,6 +46,8 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
## 网络和网络策略
|
||||
|
||||
* [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，提供网络和网络策略。
|
||||
|
|
|
|||
|
|
@ -157,6 +157,16 @@ up logging for COS image on GCP in the corresponding
|
|||
脚本为
|
||||
[`configure-helper` 脚本](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/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 flags `container-log-max-size` and `container-log-max-files` 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 标志 `container-log-max-size`
|
||||
和 `container-log-max-files` 可以用来配置每个日志文件的最大长度
|
||||
和每个容器可以生成的日志文件个数上限。
|
||||
|
||||
<!--
|
||||
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
|
||||
|
|
@ -166,14 +176,15 @@ reads directly from the log file. The kubelet returns the content of the log fil
|
|||
节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。
|
||||
|
||||
<!--
|
||||
If an external system has performed the rotation,
|
||||
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 >}}
|
||||
如果有外部系统执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。
|
||||
如果有外部系统执行日志轮转或者使用了 CRI 容器运行时，那么 `kubectl logs`
|
||||
仅可查询到最新的日志内容。
|
||||
比如，对于一个 10MB 大小的文件，通过 `logrotate` 执行轮转后生成两个文件，
|
||||
一个 10MB 大小，一个为空，`kubectl logs` 返回最新的日志文件，而该日志文件
|
||||
在这个例子中为空。
|
||||
|
|
|
|||
|
|
@ -247,15 +247,14 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
|||
|
||||
<!--
|
||||
### kube-scheduler metrics
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
|
||||
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.
|
||||
-->
|
||||
### kube-scheduler 指标 {#kube-scheduler-metrics}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< 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 的实际资源用量
|
||||
|
|
@ -287,7 +286,7 @@ kube-scheduler 组件能够辩识各个 Pod 所配置的资源
|
|||
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.
|
||||
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 阶段，或者已经被删除且所有容器都具有
|
||||
|
|
@ -299,6 +298,42 @@ endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1
|
|||
`--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" %}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
Loading…
Reference in New Issue