metrics
This commit is contained in:
huanqing.shao
@ -99,6 +99,7 @@ meta:
|
||||
* [使用port-forward访问集群中的应用程序](/learning/k8s-practice/access/port-forward.html)
|
||||
* [Kubernetes网络模型](/learning/k8s-intermediate/service/network.html)
|
||||
* [CI/CD集成](/guide/cicd/)
|
||||
* [容器应用的设计原则、模式和反模式](/learning/k8s-practice/micro-service/design-pattern.html)
|
||||
* 下一步，可按教程章节顺序对 Kubernetes 各种概念进行深入理解
|
||||
:::
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
vssueId: 174
|
||||
layout: LearningLayout
|
||||
description: Kubernetes教程_本文解释了Kubernetes中为什么ping Service 不能成功的原因
|
||||
description: Kubernetes教程_本文解释了Kuboard中度量信息的获取方式
|
||||
meta:
|
||||
- name: keywords
|
||||
content: Kubernetes教程,K8S教程,Kubernetes Service
|
||||
@ -10,3 +10,34 @@ meta:
|
||||
# Metrics
|
||||
|
||||
Kuboard 界面上显示 Metrics（性能指标）信息时，调用了 Kubernetes 的 [Metrics API](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)，
|
||||
|
||||
## 为什么 Kuboard 显示的总内存比机器的实际内存要小？
|
||||
|
||||
Kuboard 调用 kubernetes api [Node v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#node-v1-core) 获取节点的总内存信息。该接口返回结果中，关于内存信息有如下两个部分：
|
||||
|
||||
``` json
|
||||
"status": {
|
||||
"capacity": {
|
||||
"cpu": "2",
|
||||
"ephemeral-storage": "41147472Ki",
|
||||
"hugepages-1Gi": "0",
|
||||
"hugepages-2Mi": "0",
|
||||
"memory": "7733512Ki",
|
||||
"pods": "110"
|
||||
},
|
||||
"allocatable": {
|
||||
"cpu": "2",
|
||||
"ephemeral-storage": "37921510133",
|
||||
"hugepages-1Gi": "0",
|
||||
"hugepages-2Mi": "0",
|
||||
"memory": "7631112Ki",
|
||||
"pods": "110"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
其中，`capacity` 代表节点的总容量，`allocatable` 代表 kubernetes 可以使用的容量。Kuboard 在 `计算资源` 界面上显示的节点总内存大小来自于此接口返回结果的 `status.allocatable.memory` 字段，总CPU大小来自于 `status.allocatable.cpu` 字段。
|
||||
|
||||
## 为什么 Kuboard 显示的当前使用内存与linux显示不匹配？
|
||||
|
||||
Kuboard 调用 kubernetes [Metrics API](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) 获取节点 CPU 和内存使用情况，metrics-server 通过节点上的 kubelet 获取 30s 时间窗口内的 CPU 和内存使用情况，且其统计口径是由 kubelet 管理的 docker 进程的 CPU 和内存使用情况，与直接使用 linux 的 `top` 命令或 `free -h` 命令查看时的统计口径并不相同。
|
||||
|
||||
12
learning/faq/request-limit.md
Normal file
12
learning/faq/request-limit.md
Normal file
@ -0,0 +1,12 @@
|
||||
---
|
||||
# vssueId: 174
|
||||
layout: LearningLayout
|
||||
description: Kubernetes教程_本文解释了Kubernetes中为什么ping Service 不能成功的原因
|
||||
meta:
|
||||
- name: keywords
|
||||
content: Kubernetes教程,K8S教程,Kubernetes Service
|
||||
---
|
||||
|
||||
# 为什么CPU内存使用率很低，却不能调度？
|
||||
|
||||
请查看 [带有资源请求的容器组是如何调度的](/learning/k8s-intermediate/config/computing-resource.html#带有资源请求的容器组是如何调度的)
|
||||
19
learning/k8s-intermediate/config/affinity.md
Normal file
19
learning/k8s-intermediate/config/affinity.md
Normal file
@ -0,0 +1,19 @@
|
||||
---
|
||||
vssueId: 64
|
||||
layout: LearningLayout
|
||||
description: Kubernetes教程_Kubernetes中的亲和性与反亲和性_Affinity_and_Anti-Affinity
|
||||
meta:
|
||||
- name: keywords
|
||||
content: Kubernetes教程,K8S教程,Affinity,anti-affinity,亲和性,反亲和性
|
||||
---
|
||||
|
||||
# 亲和性与反亲和性
|
||||
|
||||
> 参考文档：[Affinity and anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
`nodeSelector` 提供了一个非常简单的方式，将 Pod 限定到包含特定标签的节点上。亲和性与反亲和性（affinity / anti-affinity）特性则极大地扩展了限定的表达方式。主要的增强点在于：
|
||||
1. 表达方式更加有效（不仅仅是多个精确匹配表达式的“和”关系）
|
||||
2. 可以标识该规则为“soft” / “preference” （软性的、偏好的）而不是 hard requirement（必须的），此时，如果调度器发现该规则不能被满足，Pod 仍然可以被调度
|
||||
3. 可以对比节点上（或其他拓扑域 topological domain）已运行的其他 Pod 的标签，而不仅仅是节点自己的标签，此时，可以定义类似这样的规则：某量类 Pod 不能在同一个节点（或拓扑域）上共存
|
||||
@ -77,9 +77,14 @@ nodeSelector 是 PodSpec 中的一个字段。指定了一组名值对。节点
|
||||
|
||||
此时您已完成了通过 nodeSelector 为 Pod 指定节点的任务。
|
||||
|
||||
## Node isolation/restriction <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
## Node isolation/restriction
|
||||
|
||||
向节点对象添加标签后，可以将 Pod 指定到特定（一个或一组）的节点，以便确保某些 Pod 只在具备某些隔离性、安全性或符合管理规定的节点上运行。如果将标签用于这个目的，推荐选择那些不会被 kubelet 修改的标签。这样做可以避免节点非法使用其 kubelet credential 来设置节点自己的标签，进一步影响到调度器将工作负载调度到该节点上。
|
||||
|
||||
`NodeRestriction` 管理插件可以阻止 kubelet 设置或者修改节点上以 `node-restriction.kubernetes.io/` 开头的标签。如需要使用该标签前缀作为节点隔离的目的，需要：
|
||||
1. 确保 kubenetes 已经启用了 [Node authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/) 和 [NodeRestriction admission plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
2. 添加带 `node-restriction.kubernetes.io/` 前缀的标签到节点对象，并将这些标签作为 Pod 中的节点选择器。例如： `example.com.node-restriction.kubernetes.io/fips=true` 或 `example.com.node-restriction.kubernetes.io/pci-dss=true`。
|
||||
|
||||
请参考 Kubernetes 官网文档 [Node isolation/restriction](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-isolation-restriction)
|
||||
|
||||
## Affinity and anti-affinity <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
|
||||
|
||||
@ -71,7 +71,7 @@ meta:
|
||||
|
||||
- 捕获并响应Terminate (SIGTERM)信号，来尽快优雅的终止服务进程，以避免kill (SIGKILL)信号强行终止进程。例如一下的NodeJS代码。
|
||||
|
||||
```
|
||||
``` go
|
||||
process.on('SIGTERM', function () {
|
||||
console.log("Received SIGTERM. Exiting.")
|
||||
server.close(function () {
|
||||
@ -84,7 +84,7 @@ meta:
|
||||
|
||||
- 返回退出码
|
||||
|
||||
```
|
||||
``` go
|
||||
process.exit(0);
|
||||
```
|
||||
|
||||
@ -214,7 +214,7 @@ Sidecar是最常见的模式，在同一个Pod中，我们需要把不同的责
|
||||
|
||||
通常作为服务的容器有一个启动的过程，在启动过程中，服务是不可用的。Kubernetes提供了[Readiness](/learning/k8s-intermediate/workload/pod-lifecycle.html#容器的检查)探测功能。
|
||||
|
||||
```
|
||||
``` yaml
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /
|
||||
@ -233,7 +233,7 @@ readinessProbe:
|
||||
|
||||
例如下面的Dockerfile例子：
|
||||
|
||||
```
|
||||
``` dockerfile
|
||||
FROM ubuntu:14.04
|
||||
|
||||
RUN apt-get update
|
||||
@ -257,7 +257,7 @@ Latest标签用于标记最近的稳定版本，然而在创建容器时，尽
|
||||
|
||||
Job是Kubernetes提供的只运行一次的容器，和service正好相反。要避免快速失败
|
||||
|
||||
```
|
||||
``` yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
|
||||
Reference in New Issue
Block a user