CPU CgroupCgroups 是对指定进程做计算机资源限制的，CPU Cgroup 是 Cgroups 其中的一个 Cgroups 子系统，它是用来限制进程的 CPU 使用的。对于进程的 CPU 使用，我们知道它只包含两部分：一个是用户态（top命令中的 us 和 ni）；还有一部分是内核态（top 命令中的 sy）。至于其他状态（top 命令中的 wa、hi、si），这些 I/O 或者中

现象在执行./deploy.sh -s | kubectl apply -f -升级CoreDNS过程中，如果遇到以下提示：The Deployment "coredns" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kube

问题描述：k8s版本1.25.3，kube-controller-manager使用https监听端口10257。监控Target页面显示DOWN，错误提示server returned HTTP status 403 Forbidden，点击metrics url 提示：{"kind": "Status","apiVersion": &

kubeadm部署kubernetes备份etcd由于kubeadm部署的kubernetes是以容器形式运行etcd，所以在系统中没有etcdctl的命令，如果需要在系统中备份，则可以下载etcd二进制包来使用etcdctl命令。查看版本下载工具通过kubectl在容器中执行etcdctl version来查看etcd版本：# kubectl exec -it -n kube-system et

参考：默认 Ingress 类你可以将一个特定的 IngressClass 标记为集群默认 Ingress 类。 将一个 IngressClass 资源的ingressclass.kubernetes.io/is-default-class注解设置为true将确保新的未指定ingressClassName字段的 Ingress 能够分配为这个默认的 IngressClass。比如修改Ingress

有一个项目，它有自己的MySQL数据库核Redis缓存中间件，我们只希望这个项目的应用能够访问该中间件。假如有一个项目需要通过Ingress进行对外发布，我们想要除了Ingress外，其他的Namespace下的Pod都不能访问该项目。假设有一个项目叫nw-demo，里面部署了三个微服务，分别是MySQL、Redis和Nginx。现需要对MySQL、Redis、Nginx进行隔离，分别实现如下效果

启动进程命名空间共享机制，只需要在 Pod 定义中设置shareProcessNamespace=true即可完成。通过下面例子展示一个 Pod 中两个容器共享进程命名空间的效果，share-process-namespace.yaml 配置文件的内容如下：apiVersion: v1kind: Podmetadata: name: nginxspec: shareProcessNamespa

根据集群用户数量来调整集群配置，以达到这个目的：能控制特定命名空间中的资源使用量，最终实现集群的公平使用和成本控制。需要实现的功能如下：限制运行状态的 Pod 的计算资源用量。限制持久卷的数量以控制对存储的访问。限制负载均衡器的数量以控制成本。防止滥用网络端口这类稀缺资源。提供默认的计算资源 Requests 以便系统做出更优化的调度。1. 创建命名空间创建名为 quota-example 的命名

资源配额管理（Resource Quotas）通过 ResourceQuota 对象，可以定义资源配额，这个资源配额可以为每个命名空间都提供一个总体的资源限制：它可以限制命名空间中某种类型的对象的总数量上限，也可以设置命名空间中 Pod 可以使用的计算资源的总上限。在使用资源配额时，需要注意以下两点：如果集群中总的可用资源小于各命名空间中资源配额的总和，那么可能会导致资源竞争。在发生资源竞争时，K

1. Requests 和 Limits 对不同计算机资源类型的限制机制容器的资源配置满足以下两个条件：Requests ≤ 节点可用资源Requests ≤ Limits1) 可压缩资源Kubernetes 目前支持的可压缩资源是 CPU。Pod 可以得到 Requests 配置的CPU 使用量，而能否使用超过 Requests 值的部分取决于系统的负载和调度。空闲的 CPU 资源按照容器 Re

Kubernetes 提供了 LimitRange 机制对 Pod 和容器的 Requests 和 Limits 配置做进一步限制。下面的示例中首先如何将 LimitsRange 应用到一个 Kubernetes 的命名空间中，然后说明 LimitRange 的几种限制方式，比如最大及最小范围、Requests 和 Limits 的默认值、Limits 与 Requests 的最大比例上线，等等。

kubernetes 通过 Namespace (命名空间)和 Context 的设置对不同的工作组进行区分，使得它们既可以共享一个 Kubernetes 集群的服务，也可以互不干扰。创建Namespace为了在 Kubernetes 集群中实现这两个分组，首先需要创建两个命名空间。使用 namespace-development.yaml，创建 development 命名空间：apiVersi

Node 的隔离与恢复Kubernetes在硬件升级、维护等情况下。需要将某些Node隔离，使其脱离Kubernetes集群的调度范围。Kubernetes提供了一种机制，既可以将Node纳入调度范围，也可以将Node脱离调度范围。可以使用YAML文件或者kubectl命令进行调整。1.使用YAML文件创建配置文件unschedule_node.yaml，在spec部分指定unschedulabl

Kubernetes管理的Node本地存储卷（Volume）的类型如下。EmptyDir：与Pod同生命周期的Node临时存储。HostPath：Node目录。Local：基于持久卷（PV）管理的Node目录。对如何以存储卷的形式使用说明如下：1. EmptyDir这种类型的Volume在Pod被调度到Node时进行创建，在初始状态下目录中是空的，所以命名为“空目录”（Empty Director

在Kubernetes中有一些资源对象可以以存储卷的形式挂载为容器内的目录或文件，目前包括ConfigMap、Secret、Downward API、ServiceAccountToken、Projected Volume。1. ConfigMapConfigMap主要保存应用程序所需的配置文件，并且通过Volume形式挂载到容器内的文件系统中，供容器内的应用程序读取。apiVersion: v1

Network Policy的主要功能是对Pod或者Namespace之间的网络通讯进行限制和准入控制，设置方式为将目标对象的Label作为查询条件，设置允许访问或禁止访问的客户端Pod列表。目前查询条件可以作用于Pod和Namespace级别。网络策略设置说明网络策略的设置主要用于对目标Pod的网络访问进行控制，在默认情况下对所有Pod都是允许访问的，在设置了指向Pod的NetworkPolic

一般来说，智能系统和自动系统通常都会通过一个“操作系统”不断修正系统的工作状态。在Kubernetes集群中，每个Controller都是这样的一个“操作系统”，它们通过API Server 提供的（List-Watch）接口实时监控集群中特定资源的状态变化。当发生各种故障导致某资源对象的状态变化时，Controller会尝试将其状态调整为期望的状态。比如当某个Node意外宕机时，Node Con

概要kubernetes 部署连接：Installation Guide - NGINX Ingress Controller本案例使用yaml的方式部署，分为3个步骤：部署Ingress Controller创建 Ingress 策略客户端通过 Ingress Controller 访问后端 webapp 服务1. 部署 Ingress Controlleringress.yaml 内容如下：

在默认情况下，Pod 的名称将被系统设置为容器环境内的主机名称（hostname），但通过副本控制器创建的 Pod 名称会有一段随机后缀名，无法固定，此时可以通过 Pod yaml 配置中设置 hostname 字段定义容器环境的主机名。同时，可以设置 subdomain字段定义容器环境的子域名。通过下面文件对的 Pod 定义，将会在 Pod 容器环境中设置主机名为“webapp-1”，子域名为“

Pod作为集群中提供具体服务的实体，也可以像Service一样设置DNS域名。另外，系统为客户端应用Pod提供需要使用的DNS策略提供多种选择。Pod 域名对Pod来说，Kubernetes会为其设置一个<pod-ip>.<namespace>.pod.<cluster-domain>格式的DNS域名，其中Pod IP部分需要用"-“替换”."