k8s学习笔记（10）--- kubernetes核心组件之controller manager详解

最新推荐文章于 2024-04-23 06:42:08 发布
最新推荐文章于 2024-04-23 06:42:08 发布
阅读量5k 收藏 28
点赞数 2
分类专栏： K8S
原文链接：https://blog.csdn.net/qq_42987484/article/details/104236013
版权
K8S 专栏收录该内容
104 篇文章 134 订阅
订阅专栏

kubernetes核心组件之controller manager详解

一、Controller Manager简介

         Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
在这里插入图片描述
         每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。

1.1 Replication Controller

         controller manager 中的 Replication controller(副本控制器) 和 K8S 中的资源 replication controller 不是同一个东西, 为了区别, 此处将资源类型的 replication controller 用RC 表示, controller manager 中的replication controller 仍然用 replication controller 表示,指代副本控制器。

         replication controller 的核心作用是保障集群中某个 RC 关联的pod副本数与预设值一致. 当pod 重启策略为always 时(RestartPolicy=Always), Replication Controller 才会管理该 POD 的操作(创建, 销毁, 重启等), 在默认情况下, POD 对象被创建成功后不会消失, 唯一例外是当pod 处于succeed 或failed 状态的实践过长(超时参数由系统设定)时, 该pod 会被系统自动回收, 管理该 pod 的副本控制器将在其他工作节点上重新创建,运行该POD 副本。

         RC 中的POD 模版就像模具, POD 一旦通过模版制作出来,就和RC 再也没有联系了. 无论模版如何变化, 甚至换成一个新的模版, 也不会影响到已经创建的POD . 因此POD 可以通过修改标签来脱离 RC 的管控. 改方法可以用于将POD 从集群中迁移, 数据修复等调试。

  • replication controller 的职责
  1. 确保集群中有且仅有N 个POD的实例, N 是RC 中定义的POD 副本数量;
  2. 通过调整 RC 的 spec.replicas 属性值来扩容或缩容;
  3. 通过改变 RC 中的 POD 模版(主要是镜像), 来实现滚动升级;
  • replication controller 的使用场景
  1. 重新调度。当发生节点故障或Pod被意外终止运行时，可以重新调度保证集群中仍然运行指定的副本数。
  2. 弹性伸缩。通过手动或自动扩容代理修复副本控制器的spec.replicas属性，可以实现弹性伸缩。
  3. 滚动升级。创建一个新的RC文件，通过kubectl 命令或API执行，则会新增一个新的副本同时删除旧的副本，当旧副本为0时，删除旧的RC。

当 RC 的spec.relicas 设置为0 时, 相关pod 将会被删除

1.2 Node Controller

         kubelet在启动时会通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server接收到信息后将信息更新到etcd中。
在这里插入图片描述
         Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能。流程如下

  1. controller manager 判断是否有 --cluster-cidr 参数, 如果有在每个节点设置spec.PodCIDR 并保障cidr 不冲突；
  2. 逐个读取Node 信息, 多次尝试修改nodeStatusMap中的节点状态信息, 将该节点信息和 Node Controller 的 nodeStatusMap 中保存的信息作比较；
    A. 如果判断出没有收到 kubelet 发送的信息, 第一次收到 kubelet 发送的的节点信息, 或在该处理过程中节点状态编程非"健康", 则在 nodeStatusMap 中保存该节点状态信息, 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间。
    B. 如果判断出在指定时间内受到的新的节点信息, 且节点状态发生变化, 则在 nodeStatusMap 中保存该界节点的状态信息. 并用 Node Controller 所在节点的系统时间,作为探测时间和节点状态变化时间。
    C. 如果判断出在指定时间内收到新的节点信息, 但状态没有变化则在 nodeStatusMap 中保存该节点的状态信息. 并用 Node Controller 所在节点的系统时间作为探测时间, 将上次节点信息中的节点状态变化时间作为该节点的状态变化时间. 如果判断出某段时间(gracePeriod) 内没有收到节点状态信息, 则设置节点状态为"位置", 并通过api server 保存节点状态。
  3. 逐个读取节点信息, 如果节点状态变为非"就绪"状态, 则将节点加入待删除队列, 否则将节点从该队列删除. 如果节点为非就绪状态, 且系统指定了 cloud provider, 则 Node Controller 调用 cloud provider 查看节点, 若发现节点故障 则删除etcd中的信息, 并删除该节点相关的pod 等资源信息。

1.3 ResourceQuota Controller

         K8S 的配额管理是通过admiss control 来控制的, admission control 当前提供了两种方式进行配额约束, 分别是 LimitRanger 与 ResourceQuota. 其中 LimitRanger 作用于 POD 和 Container , ResourceQuota 作用于 Namespace。

         资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。 支持三个层次的资源配置管理：
1）容器级别：对CPU和Memory进行限制
2）Pod级别：对一个Pod内所有容器的可用资源进行限制
3）Namespace级别：包括Pod数量、Replication Controller数量、Service数量、ResourceQuota数量、Secret数量、可持有的PV（Persistent Volume）数量

1、k8s配额管理是通过Admission Control（准入控制）来控制的；
2、Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota；
3、LimitRanger作用于Pod和Container；
4、ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。

  • ResourceQuota controller 流程图在这里插入图片描述

    1.4 ResourceQuota Controller

         用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。

         如果Namespace被API标记为优雅删除（即设置删除期限，DeletionTimestamp）,则将该Namespace状态设置为“Terminating”,并保存到etcd中。同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。

1.5 Endpoint Controller

         Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。

如果监测到Service被删除，则删除和该Service同名的Endpoints对象；
如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。
如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。

         Service、Endpoint、Pod的关系：
在这里插入图片描述
         kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。

1.6 Service Controller

         Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service变化，如果是一个LoadBalancer类型的Service，则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。

二、kube-controller-manager启动参数详解

Usage:

kube-controller-manager [flags]
  • Debugging flags
参数说明
 --contention-profiling启用了 profiling，则启用锁争用性分析
 --profiling开启profilling，通过web接口host:port/debug/pprof/分析性能
  • Generic flags
参数说明
 --allocate-node-cidrs是否应在云提供商上分配和设置Pod的CIDR
 --cidr-allocator-type stringCIDR分配器的类型 (default “RangeAllocator”)
 --cloud-config string云提供商配置文件路径，空代表没有配置文件
 --cloud-provider string云提供商，空代表没有云提供商
 --cluster-cidr string集群中Pod的CIDR范围，要求–allocate-node-cidrs为true
 --cluster-name string集群的实例前缀(default “kubernetes”)
 --configure-cloud-routes是否在云提供商上配置allocate-node-cidrs分配的CIDR(default true)
 --controller-start-interval duration启动controller manager的间隔时间
 --controllers strings需要开启的controller列表，*代表开启所有（默认），‘foo’代表开启foo controller，‘-foo’代表禁止foo controller。
所有的controller如下：
attachdetach, bootstrapsigner, clusterrole-aggregation,cronjob, csrapproving, csrcleaner, csrsigning, daemonset,deployment, disruption, endpoint, garbagecollector,horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume-binder, persistentvolume-expander, podgc, pv-protection,pvc-protection, replicaset, replicationcontroller,resourcequota, route, service, serviceaccount, serviceaccount-token,statefulset, tokencleaner, ttl,ttl-after-finished
 --feature-gates mapStringBoolkey = value对，用于试验
 --kube-api-burst int32发送到kube-apiserver每秒请求量 （default 100）
 --kube-api-content-type string发送到kube-apiserver请求内容类型（default “application/vnd.kubernetes.protobuf”）
 --kube-api-qps float32与kube-apiserver通信的qps（default 50）
 --leader-elect多个master情况设置为true保证高可用，进行leader选举
 --leader-elect-lease-duration duration当leader-elect设置为true生效，选举过程中非leader候选等待选举的时间间隔（default 15s）
 --leader-elect-renew-deadline durationeader选举过程中在停止leading，再次renew时间间隔，小于或者等于leader-elect-lease-duration duration，也是leader-elect设置为true生效（default 10s）
 --leader-elect-retry-period duration当leader-elect设置为true生效，获取leader或者重新选举的等待间隔（default 2s）
 --min-resync-period duration重新同步周期,在 [MinResyncPeriod-2 * MinResyncPeriod]间取随机值(default 12h0m0s)
 --node-monitor-period durationNodeController同步NodeStatus的时间间隔(default 5s)
 --route-reconciliation-period duration协调由云提供商为节点创建的路由的时间间隔 (default 10s)
 --use-service-account-credentials设置true为每个控制器使用单个service account
  • Service controller flags
参数说明
 --concurrent-service-syncs int32允许同时同步的 service 数量。 数字越大=服务管理响应越快，但消耗更多 CPU 和网络资源
  • Secure serving flags
参数说明
 --bind-address ip监听–secure-port端口的IP地址(default 0.0.0.0)
 --cert-dir stringTLS证书所在的目录。如果提供了–tls-cert-file和–tls-private-key-file，则将忽略此标志(default “/var/run/kubernetes”)
 --http2-max-streams-per-connection intapi server 提供给 client 的HTTP / 2最大 stream 连接数。0 用golang的默认值
 --secure-port int使用身份验证和授权提供服务的HTTPS端口。0禁用HTTPS
 --tls-cert-file string文件包含HTTPS的默认x509证书的文件。 （如果有CA证书，在服务器证书之后级联）。如果启用了HTTPS服务，但是 --tls-cert-file和–tls-private-key-file 未设置，则会为公共地址生成自签名证书和密钥，并将其保存到–cert-dir的目录中
 --tls-cipher-suites strings逗号分隔的cipher suites列表。如果省略则使用默认的Go cipher suites
 --tls-min-version string支持最低TLS版本。 主要有：VersionTLS10，VersionTLS11，VersionTLS12
 --tls-private-key-file string文件包括与 --tls-cert-file 匹配的默认x509私钥
 --tls-sni-cert-key namedCertKeyx509证书和私钥对的文件路径(default []) Examples: “example.crt,example.key” or “foo.crt,foo.key:*.foo.com,foo.com”
  • Insecure serving flags
参数说明
 --address ip为不安全端口提供服务的IP地址(对于所有IPv4设置为0.0.0.0)接口和::所有IPv6接口)。(默认值0.0.0.0)(已弃用:参见 --bind-address代替。)
 --port int为不安全、未经身份验证的访问提供服务的端口。设置为0禁用。(默认10252)(弃用:参见 --secure-port)
  • Authentication flags
参数说明
 --authentication-kubeconfig stringkubeconfig文件指向有权力创建tokenaccessreviews.authentication.k8s.io的核心kubernetes server，如果未设置所有的token请求被视为匿名的，在集群中也不查找client CA
 --authentication-skip-lookup如果设置false，authentication-kubeconfig用来在集群中查找缺失的authentication配置
 --authentication-token-webhook-cache-ttl duration来自webhook token验证器的缓存响应时间 (default 10s)
 --client-ca-file string如果设置任何请求必须提供其中一个客户端证书签名。则用其中的 Common Name 作为请求的用户名验证
 --requestheader-allowed-names strings客户端证书通用名称列表，允许在–requestheader-username-headers指定的标头中提供用户名。如果为空，则允–requestheader-client-ca-file中验证的任何客户端证书。
 --requestheader-client-ca-file string根证书包，用于在信任由–requestheader-username-headers指定的头文件中的用户名之前对传入请求验证客户端证书。警告:通常不要依赖于对传入请求已经进行的授权。
 --requestheader-extra-headers-prefix strings要检查的请求头前缀列表。建议X-Remote-Extra-。(默认[x-remote-extra -])
 --requestheader-group-headers strings要检查组的请求标头列表。建议X-Remote-Group。(默认[x-remote-group])
 --requestheader-username-headers strings检查用户名的请求头列表。X-Remote-User是常用的。(默认[x-remote-user])
  • Authorization flags
参数说明
 --authorization-always-allow-paths strings授权期间要跳过的HTTP路径列表，这些路径是经过授权、无须与’核心’kubernetes服务通信(default [/healthz])
 --authorization-kubeconfig stringkubeconfig指向核心的kubernetes服务拥有足够的权力来创建subjectaccessreviews.authorization.k8s.io，也是可选项，如果未设置，则所有请求将被禁止
 --authorization-webhook-cache-authorized-ttl duration从webhook授权器对于cache验证响应时间(default 10s)
 --authorization-webhook-cache-unauthorized-ttl duration从webhook授权器对于cache验证未响应时间(default 10s)
  • Attachdetach controller flags
参数说明
 --attach-detach-reconcile-sync-period duration在volume attach detach调整同步等待时间，时间间隔必须大于1s，增加默认值可能导致volume与pod不匹配(default 1m0s)
 --disable-attach-detach-reconcile-sync禁止volume attach detach 调整同步，禁用此功能可能会导致卷与 pod 不匹配
  • Csrsigning controller flags
参数说明
 --cluster-signing-cert-file string包含peme编码的X509 CA证书的文件名，用于发出集群范围的证书(默认为“/etc/kubernetes/ CA / CA .pem”)
 --cluster-signing-key-file string包含pemm编码的RSA或ECDSA私有密钥的文件名，用于对集群范围的证书进行签名(默认为“/etc/kubernetes/ca/ca.key”)
 --experimental-cluster-signing-duration duration签署证书的期限将会被给出。(默认8760h0m0s)
  • Deployment controller flags
参数说明
 --concurrent-deployment-syncs int32允许同时同步的deployment对象的数量，部署数量越大需要的CPU网络load也多(default 5)
 --deployment-controller-sync-period duration同步deployment的周期(default 30s)
  • Endpoint controller flags
参数说明
 --concurrent-endpoint-syncs int32同时同步endpoint的数量，也是数量越多需要越多的CPU和network(default 5)
  • Garbagecollector controller flags
参数说明
 --concurrent-gc-syncs int32允许同时同步的garbage collector workers数量(default 20)
 --enable-garbage-collector启用通用垃圾收集器，必须与kube-apiserver的相应参数一起使用(default true)
  • Horizontalpodautoscaling controller flags
参数说明
 --horizontal-pod-autoscaler-cpu-initialization-period duration当CPU samples略过，在pod启动之后的周期(default 5m0s)
 --horizontal-pod-autoscaler-downscale-stabilization durationautoscaler将向后查看并且不会缩小到低于其在此期间提出的任何建议的时间段(default 5m0s)
 --horizontal-pod-autoscaler-initial-readiness-delay durationpod启动后的一段时间，在此期间战备状态的变化将被视为初始战备状态(默认为30秒)
 --horizontal-pod-autoscaler-sync-period durationThe period for syncing the number of pods in horizontal pod autoscaler. (default 15s)
 --horizontal-pod-autoscaler-tolerance float水平pod自动调度器所需的实际度量比的最小变化(从1.0开始)需要考虑缩放。(default 0.1)
  • Namespace controller flags
参数说明
 --concurrent-namespace-syncs int32允许并发同步的名称空间对象的数量。更大的数字=响应更快的名称空间终止，但是更多的CPU(和网络)负载(默认为10)
 --namespace-sync-period duration同步namespace生命周期更新的周期(default 5m0s)
  • Nodeipam controller flags
参数说明
 --node-cidr-mask-size int32集群中节点子网掩码打小(default 24)
 --service-cluster-ip-range string集群service的cidr范围，需要–allocate-node-cidrs设置为true
  • Nodelifecycle controller flags
参数说明
 --enable-taint-manager如果设置为true则开启NoExecute Taints，将驱逐所有节点上（拥有这种污点的节点）不容忍运行pod (default true)
 --large-cluster-size-threshold int32NodeController出于驱逐逻辑目的而将集群视为大节点的节点数量。对于这种大小或更小的集群(默认为50),–secondary-node-eviction-rate被隐式覆盖为0
 --node-eviction-rate float32当zone健康node失败情况，删除节点上的pod的速率 (default 0.1)
 --node-monitor-grace-period duration在标记节点不健康之前，允许运行节点不响应的时间，必须是n倍的kubelet’s nodeStatusUpdateFrequency，N意味着kubelet报告node状态重试的次数(default 40s)
 --node-startup-grace-period duration在标记节点不健康之前，允许开始节点不响应的时间 (default 1m0s)
 --pod-eviction-timeout duration在失败的节点上删除pod的宽限时间 (default 5m0s)
 --secondary-node-eviction-rate float32当zone不健康node失败情况，删除节点上的pod的速率，如果集群大小小于 large-cluster-size-threshold，则隐式地将设置为0。(default 0.01)
 --unhealthy-zone-threshold float32not ready 节点（至少3个）的比例达到该值时，将 Zone 标记为不健康 (default 0.55)
  • Persistentvolume-binder controller flags
参数说明
 --enable-dynamic-provisioning为支持它的环境启用动态配置 (default true)
 --enable-hostpath-provisioner当没有云提供商运行时开启host path pv配置，这主要适合测试以及开发配置features，host path配置不支持多点集群
 --flex-volume-plugin-dir string第三方插件路径 (default “/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”)
 --pv-recycler-increment-timeout-nfs int32NFS scrubber pod添加每Gi到ActiveDeadlineSeconds的时间增量(default 30)
 --pv-recycler-minimum-timeout-hostpath int32对于HostPath Recycler pod的最小ActiveDeadlineSeconds，仅使用于测试于开发，不使用于多几点集群 (default 60)
 --pv-recycler-minimum-timeout-nfs int32对于NFS Recycler pod的最小ActiveDeadlineSeconds (default 300)
 --pv-recycler-pod-template-filepath-hostpath string对于hostpaht持久卷重使用定义的模板路径，仅使用于测试于开发，不使用于多几点集群
 --pv-recycler-timeout-increment-hostpath int32对于HostPath scrubber pod每增加Gi到ActiveDeadlineSeconds的时间增量，仅使用于测试于开发，不使用于多几点集群 (default 30)
 --pvclaimbinder-sync-period duration同步pv以及pvc的周期 (default 15s)
  • Podgc controller flags
参数说明
 --terminated-pod-gc-threshold int32当终止的pod达到该值时，pod garbage collector开始删除终止pod，如果设置<=0，关闭pod garbage collector (default 12500)
  • Replicaset controller flags
参数说明
 --concurrent-replicaset-syncs int32允许同时同步的rs数量，Larger number = more responsive replica management, but more CPU (and network) load (default 5)
  • Replicationcontroller flags
参数说明
 --concurrent_rc_syncs int32允许并发同步的复制控制器的数目。更大的数字=响应更快的副本管理，但是更多的CPU(和网络)负载(默认5)
  • Resourcequota controller flags
参数说明
 --concurrent-resource-quota-syncs int32允许并发同步的资源配额数量。更大的数字=响应性更好的配额管理，但是更多的CPU(和网络)负载(默认5)
 --resource-quota-sync-period duration在系统中同步配额使用状态的周期 (default 5m0s)
  • Serviceaccount controller flags
参数说明
 --concurrent-serviceaccount-token-syncs int32允许并发同步的服务帐户令牌对象的数量。更大的数字=响应性更好的令牌生成，但是更多的CPU(和网络)负载(默认5)
 --root-ca-file string根CA 证书文件路径，如果设置的话将被用于 Service Account 的 token secret 中
 --service-account-private-key-file string包含用于对服务帐户令牌签名的pemm编码的私有RSA或ECDSA密钥的文件名
  • Ttl-after-finished controller flags
参数说明
 --concurrent-ttl-after-finished-syncs int32允许并发同步的ttl后完成的控制器工作人员的数量。(默认5)
  • Misc flags
参数说明
 --insecure-experimental-approve-all-kubelet-csrs-for-group stringThis flag does nothing.
 --kubeconfig stringkubeconfig文件路径，带有验证以及master信息
 --master stringkubernetes api server的地址，将会覆盖kubeconfig设置的值

三、kube-controller-manager安装部署

        注意：以下kube-schedule安装部署是在k8s的etcd、apiserver组件已部署后的前提下部署验证的；

  • 下载地址:https://github.com/kubernetes/kubernetes （包含了k8s所必须的组件，如kube-apiserver、kubelet、kube-scheduler、kube-controller-manager等等）
    1.在windows下进入https://github.com/kubernetes/kubernetes后，点击如CHANGELOG-1.16.md文件查看对应的版本（1.16版本）和下载的文件;
    2.选择Server Binaries的kubernetes-server-linux-amd64.tar.gz下载；
    3.在windows下载后通过lrzsz工具执行rz上传到linux上（linux上无法直接通过wget https://dl.k8s.io/v1.16.4/kubernetes.tar.gz下载）;
    4.解压后生成kubernetes目录，把/kubernetes/service/bin/下的kube-controller-manager复制到/opt/kubernetes/bin下；

  • 创建controller manager配置文件kube-controller-manager

      cat > /opt/kubernetes/cfg/kube-controller-manager <<EOF
  KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true \
  --v=4 \
  --master=127.0.0.1:8080 \
  --leader-elect=true \
  --address=127.0.0.1 \
  --service-cluster-ip-range=10.0.0.0/24 \
  --cluster-name=kubernetes \
  --cluster-signing-cert-file=/opt/kubernetes/ssl/ca.pem \
  --cluster-signing-key-file=/opt/kubernetes/ssl/ca-key.pem  \
  --root-ca-file=/opt/kubernetes/ssl/ca.pem \
  --service-account-private-key-file=/opt/kubernetes/ssl/ca-key.pem"
  EOF

  • systemd管理controller manager,创建kube-controller-manager服务文件

    cat > /usr/lib/systemd/system/kube-controller-manager.service <<EOF
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-controller-manager
ExecStart=/opt/kubernetes/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

  • 启动kube-controller-manager服务

      systemctl daemon-reload
  systemctl enable kube-scheduler 
  systemctl start kube-scheduler

  • 验证kube-controller-manager服务是否启动成功

      systemctl status kube-controller-manager
  
  若失败可通过查看服务日志定位问题：
  journalctl _PID=<PID>|vim -
  
  执行命令查看scheduler组件是否健康正常
  kubectl get cs controller-manager -o yaml

本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-controller-manager/

转载至https://blog.csdn.net/qq_42987484/article/details/104236013

victoruu
关注
  • 2
    点赞
  • 踩
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s学习笔记（8）--- kubernetes核心组件之scheduler详解
梦谜的博客
01-18 4272
kubernetes核心组件之scheduler详解1、kube-schedule简介1.1 kubernetes scheduler 基本原理1.1.1 scheduler 调度流程1.2 scheduler 调度策略1.2.1 Predicates（预选策略）1.2.2 Priorites（优选策略）1.3 scheduler 的优先级与抢占机制1.3.1 背景1.3.2 作用1.3.3 怎么...
Pod控制器详解
Yosigo_的博客
08-09 1108
Pod控制器详解 Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类： 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建 什么是Pod控制器 Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个
K8S学习指南(55)-K8S核心组件Controller-Manager简介
俞兆鹏的博客
01-02 1259
Controller Manager 的首要任务是管理各种控制器的生命周期。Controller Manager 通过启动、终止和监控这些控制器的运行状态，来保证集群中的各项资源按照用户定义的期望状态运行。每个控制器都有其特定的逻辑，用于监控系统状态并采取相应的行动，以保持系统状态的一致性。在控制器模式下，系统通过监控实际状态，与用户期望的状态进行比较，并采取必要的措施来使系统状态趋近于期望状态。控制器的核心是控制循环，这是一个不断运行的过程，负责监控系统状态并采取相应的操作，使实际状态趋近于期望状态。
Kubernetes 核心技术组件Controller Manager全面解析
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
04-23 1108
Controller Manager 是 Kubernetes 集群中一个核心的组件，它聚合并管理了一系列内置的 Controllers，这些 Controllers 负责监控和维护集群内各种资源对象的状态，确保集群的实际状态与用户的期望状态一致。
kubernetes组件 Controller manager深刻认知
MyySophia的博客
11-25 1249
statefuleset的rollingupdate每次只升级一个partition，也就是有状态副本集的一个实例，例如mysql实例升级版本, 待确认0没问题之后。当设置一个ReplicaSet的副本数为10的时候，如果实际的容器数小于10，则会执行调用Apiserver创建Pod。以ReplicaSet为例，它会周期地检测理想的“目标容器数”和真实的“当前容器数”是否相同。这是因为deploy这个对象出现的早，后面的对象设计演进更加先进了。同样删除的时候，会通过这个父子关系图进行级联删除。
Kubernetes核心原理（二）之Controller Manager
mamengna的博客
12-10 363
1. Controller Manager简介 Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。 每个Controller通过API Server提供的接口实时监控整个集群的每个
kube-Controller Manager 原理
qq1010267837的博客
07-20 1796
ControllerManager作为集群内部的管理控制中心，负责集群内Node、Pod副本、服务端Endpoint、服务账号（ServiceAccount）、命名空间（Namespace）、资源定额（Resoucequota）等的管理，当某一个节点宕机时，controllermanager会及时发现故障并执行自动化修复流程，确保集群始终处于预期的工作状态。...
k8s-rdma-sriov-dev-plugin:Kubernetes Rdma SRIOV 设备插件
05-31
[已弃用] 此存储库不再维护仍然欢迎您探索、学习和使用此处提供的代码。 或者，可以使用存储库 。k8s-rdma-sriov-dev-plugin ( ) 这是一个简单的 rdma 设备插件，支持 IB 和 RoCE SRIOV vHCA 和 HCA。 这也支持 ...
k8s-sidecar-injector：Kubernetes边车注入服务
02-03
k8s边车喷油器使用Kubernetes中的MutatingAdmissionWebhook在资源创建时将辅助工具注入新的部署中这是什么？ 在Tumblr，我们运行一些具有复杂的边车设置的容器。 kubernetes容器可以运行5个以上的其他容器，以及一些...
详解k8s组件Ingress边缘路由器并落地到微服务-kubernetes
02-25
进食，更准确的讲就是入口，即外部流量进入k8s集群必经之口。这到大门到底有什么作用？我们如何使用Ingress？k8s又是如何进行服务发现的呢？先看一张图：虽然k8s集群内部署的pod、server都有自己的IP，但是却无法...
k8s-1.16.1-搭建和操作-kubernetes安装包和详细文档笔记整理
最新发布
05-27
本资源包“k8s-1.16.1-搭建和操作-kubernetes安装包和详细文档笔记整理”提供了针对Kubernetes 1.16.1版本的详细指南，包括安装和操作步骤，对于学习和实践Kubernetes的用户来说，是一份非常宝贵的参考资料。...
kubernetes组件-kube-controller-manager
qq522044637的博客
10-10 2353
概述 控制器（controllers） 在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。 这是一个控制环的例子：房间里的温度自动调节器。 当你设置了温度，告诉了温度自动调节器你的期望状态（Desired State）。 房间的实际温度是当前状态（Current State）。 通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 在 Kubernetes 中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态。 ..
Kubernetes Controller Manager原理浅析
liyunlonghere
05-08 2181
controller manager是什么？ Controller Manager 是集群内部的管理控制中心，负责统一管理与运行不同的 Controller ，实现对集群内的 Node、Pod 等所有资源的管理。 比如当通过 Deployment 创建的某个 Pod 发生异常退出时，RS Controller 便会接受并处理该退出事件，并创建新的 Pod 来维持预期副本数。 contro...
controller-manager类型及其作用
weixin_50801368的博客
01-31 2105
controller-manager介绍
Tomcat中设置远程调试设置
热门推荐
rain的专栏
03-06 1万+
【转】Tomcat中设置远程debug方法http://hi.baidu.com/huamarco/blog/item/75c3f2a411e3ebf29152ee34.html 转自：http://blog.csdn.net/zmxj/何为远程调试？我们一般调试一个 web项目的java代码时，需要将你的tomcat服务器和你的开发工具（比如Jbuilder）集成，或需要工具的一
kube-controller-manager组件剖析
lhq1363511234的博客
04-02 845
控制器做了许多不同的事情，但是它们都通过API服务器监听资源（部署、服务等）变更，并且不论是创建新对象还是更新、删除已有对象，都对变更执行相应操作。大多数情况下，这些操作涵盖了新建其他资源或者更新监听的资源本身（例如，更新对象的status）。 总的来说，控制器执行一个“调和”循环，将实际状态调整为期望状态（在资源spec部分定义），然后将新的实际状态写入资源的status部分。控制器利用监听机制来订阅变更，但是由于使用监听机制并不保证控制器不会漏掉时间，所以仍然需要定期执行重列举操作来确保不会丢掉什么。
K8S-资源管理器
hxy1625309592的博客
07-10 702
1-什么是资源控制器 1、Controller Manager(资源控制器) 由kube-controller-manager 和 cloud-controller-manager组成， 是Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态， 并确保集群处于预期的工作状态。 2、kube-controller-manager kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程，逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都
Kubernetes Controller Manager 工作原理
weixin_38299404的博客
11-01 558
原文连接：https://blog.ihypo.net/15763910382218.html 本文基于对 Kubernetes v1.16 的源码阅读，文章有一定的源码，但我会通过配图尽量描述清晰 在 Kubernetes Master 节点中，有三个重要组件：ApiServer、ControllerManager、Scheduler，它们一起承担了整个集群的管理工作。本文尝试梳理清楚 ControllerManager 的工作流程和原理。 什么是 Controller Manager 根据官方文档的
NSX-T与K8S协同配置实战指南
- **NSX Container Plugin (NCP)**：NCP是NSX-T与Kubernetes交互的核心组件，它允许K8S集群利用NSX-T的网络和安全功能。 - **OpenvSwitch (OVS)**：OVS是Kubernetes节点上的虚拟交换机，用于实现容器间的通信。 -...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值