k8s组件kubelet参数

943次阅读
没有评论

共计 16439 个字符，预计需要花费 42 分钟才能阅读完成。

k8s组件kubelet参数

kubelet 是 Kubernetes 集群中的一个重要组件，负责管理每个节点上的容器生命周期。它是一个在每个节点上运行的守护进程，负责维护节点上运行的容器的健康状态，以及与 Kubernetes API Server 通信来实现集群管理的功能。此处记录下一些kubelet的配置参数

kubelet作用

kubelet 的主要作用包括：

  1. 容器生命周期管理：kubelet 监控容器的运行状态，包括容器的启动、停止、重启等操作，并通过 cAdvisor 等工具来收集容器的运行时数据，以便在容器出现问题时能够及时进行排查和诊断。
  2. 容器健康检查：kubelet 定期检查容器的健康状态，如果容器出现故障，kubelet 将会重启容器或将容器从节点上移除。
  3. 资源管理：kubelet 根据 Pod 的资源需求和节点的资源容量，决定在节点上调度哪些 Pod，并监控容器使用的资源情况，以确保容器不会超过其分配的资源限制。
  4. 网络管理：kubelet 管理容器的网络，并确保容器可以与其他容器和节点上的服务通信。
  5. 与 Kubernetes API Server 通信：kubelet 通过与 Kubernetes API Server 通信，将节点的状态和容器的信息汇报给 API Server，并接收来自 API Server 的指令，以便与整个集群协同工作。

在 Kubernetes 集群中，kubelet 是一个非常重要的组件，负责维护节点上容器的正常运行，保障整个集群的稳定性和可用性。

kubelet的配置参数

博主这边使用的kubeadm构建的1.18集群，可以看一下kubelet的systemd文件

[root@k8s-master kubelet]# systemctl cat kubelet
# /usr/lib/systemd/system/kubelet.service
[Unit]
Description=kubelet: The Kubernetes Node Agent
Documentation=https://kubernetes.io/docs/
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/usr/bin/kubelet
Restart=always
StartLimitInterval=0
RestartSec=10

[Install]
WantedBy=multi-user.target

# /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

kubelet的配置在configmap中，可以查看下kube-system空间

[root@k8s-master kubelet]# kubectl get cm -n kube-system
NAME                                 DATA   AGE
calico-config                        4      140d
coredns                              1      140d
extension-apiserver-authentication   6      140d
kube-proxy                           2      140d
kubeadm-config                       2      140d
kubelet-config-1.18                  1      140d
[root@k8s-master kubelet]#
[root@k8s-master kubelet]# kubectl get cm -n kube-system kubelet-config-1.18 -o yaml
apiVersion: v1
data:
  kubelet: |
    apiVersion: kubelet.config.k8s.io/v1beta1
    authentication:
      anonymous:
        enabled: false
      webhook:
        cacheTTL: 0s
        enabled: true
      x509:
        clientCAFile: /etc/kubernetes/pki/ca.crt
    authorization:
      mode: Webhook
      webhook:
        cacheAuthorizedTTL: 0s
        cacheUnauthorizedTTL: 0s
    clusterDNS:
    - 10.96.0.10
    clusterDomain: cluster.local
    cpuManagerReconcilePeriod: 0s
    evictionPressureTransitionPeriod: 0s
    fileCheckFrequency: 0s
    healthzBindAddress: 127.0.0.1
    healthzPort: 10248
    httpCheckFrequency: 0s
    imageMinimumGCAge: 0s
    kind: KubeletConfiguration
    nodeStatusReportFrequency: 0s
    nodeStatusUpdateFrequency: 0s
    rotateCertificates: true
    runtimeRequestTimeout: 0s
    staticPodPath: /etc/kubernetes/manifests
    streamingConnectionIdleTimeout: 0s
    syncFrequency: 0s
    volumeStatsAggPeriod: 0s
kind: ConfigMap
metadata:
  creationTimestamp: "2020-08-01T04:46:17Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:kubelet: {}
    manager: kubeadm
    operation: Update
    time: "2020-08-01T04:46:17Z"
  name: kubelet-config-1.18
  namespace: kube-system
  resourceVersion: "162"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kubelet-config-1.18
  uid: 93cbe4b0-9260-478e-83af-65822aaf8a0b

常用参数

cpuManagerReconcilePeriod

cpuManagerReconcilePeriod 参数用来设置 CPU Manager 在检查并调整 CPU 分配情况的时间间隔。如果将 cpuManagerReconcilePeriod 设置为 0s，表示禁用 CPU Manager 的自动 CPU 分配调整功能，即不会对节点上的 CPU 分配情况进行检查和调整。

当将 cpuManagerReconcilePeriod 设置为 0s 时，CPU Manager 将不会自动检查节点上所有运行中的 Pod 的 CPU 使用情况，也不会进行 CPU 分配调整。这意味着，节点上的 CPU 分配情况将不受 CPU Manager 的影响，而完全由 Kubernetes 的默认调度器进行管理。

在某些情况下，可能希望禁用 CPU Manager 的自动 CPU 分配调整功能，比如在节点上手动进行 CPU 分配调整时，或者在需要更精细地控制节点上的 CPU 使用情况时。但是需要注意的是，禁用 CPU Manager 的自动 CPU 分配调整功能可能会导致节点上的 CPU 使用不够高效，需要根据实际情况来决定是否需要禁用它。

evictionPressureTransitionPeriod

evictionPressureTransitionPeriod 是 kubelet 配置文件中一个用来配置 Pod 驱逐的参数，用来设置在节点资源压力转移时 Pod 驱逐的等待时间。如果将 evictionPressureTransitionPeriod 设置为 0s，表示在节点资源压力转移时不会等待，而会立即进行 Pod 驱逐。

Kubernetes 中的节点资源压力分为两种类型：NodePressureTransition 和 NodeAllocatableEnforcedTransition。当节点资源压力发生转移时，Kubernetes 会对节点上的 Pod 进行驱逐以释放资源。在这个过程中，evictionPressureTransitionPeriod 参数用来设置 Pod 驱逐的等待时间。

当 evictionPressureTransitionPeriod 设置为 0s 时，表示在节点资源压力转移时不会等待，而会立即进行 Pod 驱逐。这样可能会导致 Pod 被过早地驱逐，而导致服务中断或数据丢失等问题。因此，在生产环境中，不建议将 evictionPressureTransitionPeriod 设置为 0s，而应该根据实际情况来进行配置，以保证服务的稳定性和可靠性。

evictionSoft和evictionHard

evictionSoft 和 evictionHard 是 kubelet 配置文件中用来设置 Kubernetes 节点上 pod 被驱逐的条件的参数。

evictionSoft 定义了当节点资源（比如内存）可用空间低于某个阈值时触发的“软”驱逐。这个条件被称为软限制（soft limit），软限制的目的是在系统资源已经接近耗尽的情况下，避免一些轻微的过载导致 pod 被立即驱逐。举个例子，如果节点的内存可用空间低于 100MiB，那么 kubelet 就会尝试驱逐一些 pod 来释放内存。

evictionHard 定义了当节点资源低于某个更低的阈值时触发的“硬”驱逐。这个条件被称为硬限制（hard limit），硬限制的目的是确保节点不会在资源耗尽的情况下继续运行，避免节点出现“僵尸进程”等问题。如果节点的内存可用空间低于 50MiB，那么 kubelet 就会强制性地驱逐一些 pod 来释放内存。

可以根据集群的实际情况调整这两个参数的值，以确保节点资源的有效利用和避免节点出现资源耗尽等问题。

fileCheckFrequency

fileCheckFrequency 是 kubelet 的一个参数，用于设置 kubelet 在检查容器日志文件和容器状态文件时的频率。如果将 fileCheckFrequency 设置为 0s，表示 kubelet 不会检查这些文件，这可能会导致某些容器状态的不可预测或者延迟。

在默认情况下，fileCheckFrequency 的值为 20s。这个时间间隔可以根据实际需求进行调整。通常情况下，建议将 fileCheckFrequency 设置为一个适当的时间间隔，以保证容器的状态和日志文件的正确性。当然，如果对容器状态和日志文件的实时性要求不高，可以将 fileCheckFrequency 设置为一个较大的值，以降低 kubelet 的资源消耗。

healthzBindAddress

httpCheckFrequency 是 kubelet 的一个参数，用于设置 kubelet 在检查容器健康检查接口时的频率。如果将 httpCheckFrequency 设置为 0s，表示 kubelet 不会检查容器的健康检查接口，这可能会导致某些容器状态的不可预测或者延迟。

在默认情况下，httpCheckFrequency 的值为 10s。这个时间间隔可以根据实际需求进行调整。通常情况下，建议将 httpCheckFrequency 设置为一个适当的时间间隔，以保证容器的健康检查接口的及时性和正确性。当然，如果对容器的健康检查接口的实时性要求不高，可以将 httpCheckFrequency 设置为一个较大的值，以降低 kubelet 的资源消耗。

注意：

在 Kubernetes 中，容器的健康检查有两种方式，一种是通过在 Pod 中定义容器的健康检查，另一种是通过 kubelet 发起的健康检查。

Pod 中定义的容器健康检查是通过在 Pod 的 YAML 文件中添加 livenessProbe 和 readinessProbe 字段来实现的。这些健康检查是由 Kubernetes 控制平面直接在容器中执行的，并且具有更高的精度和可配置性。这些健康检查可以在 Pod 出现问题时自动重启容器或者从 Service 的 Endpoint 中移除不健康的 Pod。

另一方面，kubelet 发起的健康检查是在 Pod 创建后由 kubelet 周期性地向容器的健康检查端点发出的 HTTP GET 请求，以确定容器是否处于运行状态。这些健康检查可以在 Pod 中没有定义健康检查的情况下发挥作用，并且可以在容器出现问题时自动重启容器或者从 Service 的 Endpoint 中移除不健康的 Pod。

总的来说，Pod 中定义的容器健康检查具有更高的精度和可配置性，而 kubelet 发起的健康检查则是一种备选方案，可以在没有定义健康检查的情况下发挥作用。在实际使用中，通常会同时使用这两种健康检查方式，以提高容器的健康状态检测的可靠性。

httpCheckFrequency

imageMinimumGCAge

imageMinimumGCAge 是 kubelet 的配置参数之一，它用于配置容器镜像的最小垃圾回收（GC）年龄，以确保不会轻易删除较新的镜像。

具体来说，imageMinimumGCAge 参数表示镜像的最小 GC 年龄，它是一个时间段，通常以秒为单位。如果镜像的创建时间小于这个时间段，那么这个镜像将不会被 GC 删除。如果将 imageMinimumGCAge 设置为 0s，则表示所有的镜像都可以被立即 GC。

设置 imageMinimumGCAge 的目的是为了避免轻易删除最近使用的镜像，因为这些镜像很可能会再次被使用，从而降低重新拉取镜像的延迟和网络带宽消耗。同时，通过定期清理一些较早的不使用的镜像，还可以节省磁盘空间。

在生产环境中，可以根据实际情况配置 imageMinimumGCAge 参数，通常建议将其设置为几天或一周左右，以平衡性能和存储空间之间的权衡。如果在使用中发现过多的镜像占用了存储空间，可以适当缩短镜像的最小 GC 年龄来加快清理进程。

imageGCHighThresholdPercent和imageGCLowThresholdPercent

imageGCHighThresholdPercent 和 imageGCLowThresholdPercent 是 kubelet 配置文件中用来设置容器镜像垃圾回收（Garbage Collection，GC）策略的参数。

Kubernetes 中的容器镜像垃圾回收是指自动清理不再被使用的镜像以释放磁盘空间的过程。这个过程由 kubelet 在节点上自动运行，可以根据节点上的磁盘空间使用情况和节点上的容器镜像使用情况来触发。具体来说，imageGCHighThresholdPercent 和 imageGCLowThresholdPercent 是两个用来触发容器镜像垃圾回收的阈值。

当节点上的磁盘空间占用率超过 imageGCHighThresholdPercent 时，kubelet 会触发容器镜像垃圾回收。垃圾回收的目标是清理那些被标记为“不再使用”的镜像，以释放磁盘空间。当磁盘空间占用率低于 imageGCLowThresholdPercent 时，kubelet 将停止触发容器镜像垃圾回收。

默认情况下，imageGCHighThresholdPercent 的值为 85%，imageGCLowThresholdPercent 的值为 80%。可以根据节点上的磁盘空间使用情况和镜像使用情况来调整这两个阈值，以确保节点上的磁盘空间得到合理利用，避免出现磁盘空间不足的问题。

注意：

imageMinimumGCAge 和 imageGCHighThresholdPercent 是 kubelet 的两个不同配置参数，它们有不同的作用。

imageMinimumGCAge 配置项表示镜像的最小 GC 年龄，它是一个时间段，通常以秒为单位。如果镜像的创建时间小于这个时间段，那么这个镜像将不会被 GC 删除。而 imageGCHighThresholdPercent 则用于控制镜像的 GC 触发阈值，它是一个百分比，当节点上的镜像占用磁盘空间的百分比超过该值时，kubelet 会触发镜像的 GC。

在使用中，两个参数的作用不同，可以相互配合使用以达到更好的效果。imageMinimumGCAge 可以用于控制在何时删除不常使用的镜像，而 imageGCHighThresholdPercent 则可以控制节点上镜像占用磁盘空间的上限，从而避免因为磁盘空间不足而导致节点出现故障。

需要注意的是，imageGCHighThresholdPercent 是一个相对值，它是根据节点上所有镜像占用的磁盘空间大小进行计算的。因此，如果节点上的磁盘空间较小，那么需要适当降低 imageGCHighThresholdPercent 的值，以保证足够的磁盘空间供使用。同时，为了保证服务的可用性，也建议在设置这两个参数时进行谨慎评估和测试。

nodeStatusReportFrequency

nodeStatusReportFrequency 是 kubelet 的配置选项之一，用于指定 kubelet 向 kube-apiserver 汇报节点状态的频率。默认情况下，该值为 1分钟。

如果将 nodeStatusReportFrequency 设置为 0s，则 kubelet 不会主动向 kube-apiserver 汇报节点状态，而是等待 kube-apiserver 请求节点状态时再汇报。

通常情况下，应该按照默认值定期汇报节点状态。这样，kube-apiserver 就可以及时了解节点的运行状况，以便调度器在做出调度决策时考虑节点的状态，从而提高整个集群的稳定性和可用性。如果将 nodeStatusReportFrequency 设置为 0s，可能会导致 kube-apiserver 无法及时了解节点状态，从而影响调度器的调度决策。

nodeStatusUpdateFrequency

nodeStatusUpdateFrequency是kubelet的配置参数之一，用于指定kubelet更新节点状态信息的时间间隔。节点状态信息是kubelet向kube-apiserver报告的有关节点的信息，例如节点的资源使用情况、节点上运行的pod信息等等。

nodeStatusUpdateFrequency的默认值为10秒，表示kubelet每隔10秒向kube-apiserver报告一次节点状态信息。可以根据需要将其调整为更短或更长的时间间隔。如果将其设置为0，则表示kubelet不会自动更新节点状态信息，需要通过手动调用kubelet sync-node-status命令来更新节点状态信息。

需要注意的是，将nodeStatusUpdateFrequency设置为过短的时间间隔可能会对节点和集群的性能产生影响，因为频繁的状态更新可能会消耗大量的CPU和网络资源。因此，在生产环境中，应该根据实际情况谨慎调整该参数。

注意：

nodeStatusUpdateFrequency和nodeStatusReportFrequency都是kubelet的配置参数，用于控制kubelet向kube-apiserver报告节点状态信息的时间间隔。它们的区别在于：

  • nodeStatusUpdateFrequency用于控制kubelet更新节点状态信息的时间间隔，即kubelet在本地计算节点状态信息后，向kube-apiserver报告节点状态信息的时间间隔。
  • nodeStatusReportFrequency用于控制kubelet向kube-apiserver报告节点状态信息的时间间隔，即kubelet将计算后的节点状态信息上传到kube-apiserver的时间间隔。

可以理解为，nodeStatusUpdateFrequency决定了kubelet计算节点状态信息的频率，而nodeStatusReportFrequency决定了kubelet将节点状态信息上传到kube-apiserver的频率。

需要注意的是，这两个参数的默认值不同：nodeStatusUpdateFrequency的默认值为10秒，而nodeStatusReportFrequency的默认值为5分钟。在实际使用中，可以根据需要适当调整这两个参数，以便更好地平衡节点状态信息的更新和上传频率，提高集群的性能和稳定性。

rotateCertificates

rotateCertificates是kubelet的一个配置项，用于控制是否启用证书轮换功能。证书轮换可以帮助确保Kubernetes集群中的证书是最新的，从而提高安全性。

当rotateCertificates为true时，kubelet将在每次重启时轮换证书。可以使用--certificate-renewal-config-file和--rotate-certificates选项配置证书轮换参数。这些参数确定证书轮换的条件和频率。

在生产环境中，建议启用证书轮换功能，以确保证书的安全性和最新性。

runtimeRequestTimeout

runtimeRequestTimeout是kubelet的一个配置项，用于控制容器运行时请求的超时时间。如果在此时间内容器运行时无响应，则kubelet将认为请求失败，并视情况采取相应的措施。

runtimeRequestTimeout的默认值为2m（两分钟）。可以通过在kubelet配置文件中设置runtimeRequestTimeout参数的值来更改默认的运行时请求超时时间。例如，如果要将运行时请求超时时间设置为30秒，则可以将runtimeRequestTimeout设置为30s。

在生产环境中，建议根据实际情况调整runtimeRequestTimeout的值，以确保在容器运行时出现问题时能够及时处理。较短的超时时间可能会增加不必要的负载和延迟，而较长的超时时间可能会导致请求无响应而无法及时处理容器问题。

streamingConnectionIdleTimeout

streamingConnectionIdleTimeout是kubelet的一个配置项，用于控制容器日志和控制台的流式连接的空闲超时时间。如果在此时间内没有数据传输，流式连接将被关闭，以释放资源并防止资源浪费。

streamingConnectionIdleTimeout的默认值为4h（4个小时）。可以通过在kubelet配置文件中设置streamingConnectionIdleTimeout参数的值来更改默认的流式连接空闲超时时间。例如，如果要将流式连接空闲超时时间设置为5分钟，则可以将streamingConnectionIdleTimeout设置为5m。

在生产环境中，建议根据实际情况调整streamingConnectionIdleTimeout的值，以确保在长时间空闲期间释放资源并避免资源浪费。较短的超时时间可能会导致连接不断断开，而较长的超时时间可能会导致资源浪费和性能下降。

注意：

kubectl exec和kubectl log使用了基于流式连接的方式与Pod进行通信。kubectl exec命令会在Pod中创建一个新的进程，并且会将标准输入、标准输出、标准错误输出连接到该进程。这样就可以在控制台中执行命令，进行交互式操作。kubectl exec命令在连接建立后，会一直保持与Pod的连接状态，直到退出。

kubectl log命令则是从Pod的日志文件中获取日志，并将其打印到控制台上。由于日志文件通常会不断增长，所以kubectl log会一直保持与Pod的连接状态，以便获取新的日志。

runtimeRequestTimeout和streamingConnectionIdleTimeout参数是用于控制kubelet与API Server之间的连接超时时间和空闲连接关闭时间，与kubectl exec和kubectl log命令的流式连接没有直接关系。

syncFrequency

syncFrequency 是 kubelet 的一个配置参数，它指定了多长时间 kubelet 应该同步一次所有的 Pod 和相关的 Docker 容器的状态信息，以确保它们的状态是最新的。它的默认值是 1 分钟，即 60s。如果您在集群中使用了不同的调度器或 Kubernetes 版本，或者需要更频繁地更新 Pod 状态，则可以考虑缩短此值。

设置为 0s 表示禁用同步周期，即 kubelet 不会主动检查并同步容器和 Pod 状态，需要通过其他方式触发同步，比如 Kubernetes 的 API Server 上有相关事件发生。

在 kubelet 中，syncFrequency 参数控制 Pod 状态的同步。该参数指定了多久 kubelet 应该在检查状态时检查 Pod 状态。较短的同步频率会使状态更加准确，但会增加资源消耗。较长的同步频率会减少资源消耗，但会使状态更新较慢。因此，要根据需要平衡同步频率和资源消耗。

在生产环境中，可以根据系统的负载和需求进行调整，以达到最优的同步频率和资源利用率。

volumeStatsAggPeriod

volumeStatsAggPeriod 是 kubelet 的一个配置参数，表示聚合计算存储卷磁盘使用情况的时间间隔。它的默认值为 1 分钟（1m）。如果将其设置为 0，表示 kubelet 不进行存储卷磁盘使用情况的计算，这可能会影响 Kubernetes 的自动伸缩、调度等特性。

当 volumeStatsAggPeriod 设置为 0 时，kubelet 不会定期聚合计算存储卷磁盘使用情况，也不会保存上一次计算的结果。因此，当 Kubernetes 组件需要查询存储卷磁盘使用情况时，需要通过访问 CSI 插件或云供应商的 API 等方式获取数据，这可能会导致性能瓶颈和延迟增加。建议在生产环境中将 volumeStatsAggPeriod 设置为一个合适的值，以充分利用 Kubernetes 的特性并提高性能和可靠性。

调整kubelet参数

目前博主的集群式1.18，修改了kubelet的configmap后，只会影响新加入的节点

[root@k8s-master kubelet]# kubectl get cm -n kube-system kubelet-config-1.18 -o yaml
apiVersion: v1
data:
  kubelet: |
    apiVersion: kubelet.config.k8s.io/v1beta1
    authentication:
      anonymous:
        enabled: false
      webhook:
        cacheTTL: 0s
        enabled: true
      x509:
        clientCAFile: /etc/kubernetes/pki/ca.crt
    authorization:
      mode: Webhook
      webhook:
        cacheAuthorizedTTL: 0s
        cacheUnauthorizedTTL: 0s
    clusterDNS:
    - 10.96.0.10
    clusterDomain: cluster.local
    cpuManagerReconcilePeriod: 10s
    evictionPressureTransitionPeriod: 30s
    evictionSoft:
      memory.available: 1024Mi
      nodefs.available: 10Gi
      imagefs.available: 10Gi
    evictionHard:
      memory.available: 512Mi
      nodefs.available: 5Gi
      imagefs.available: 5Gi
    evictionSoftGracePeriod:
      memory.available: 30s
    fileCheckFrequency: 10s
    healthzBindAddress: 127.0.0.1
    healthzPort: 10248
    httpCheckFrequency: 60s
    imageMinimumGCAge: 129600s
    kind: KubeletConfiguration
    nodeStatusReportFrequency: 60s
    maxPods: 200
    nodeStatusUpdateFrequency: 10s
    rotateCertificates: true
    runtimeRequestTimeout: 30s
    staticPodPath: /etc/kubernetes/manifests
    streamingConnectionIdleTimeout: 15m
    syncFrequency: 60s
    volumeStatsAggPeriod: 60s
kind: ConfigMap
metadata:
  name: kubelet-config-1.18
  namespace: kube-system

对于已存在的节点并不会自动更新配置并重启kubelet，需要手动调整下一些配置

已存在节点调整/var/lib/kubelet/config.yaml

[root@k8s-master ~]# cat /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 0s
    cacheUnauthorizedTTL: 0s
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 10s
evictionPressureTransitionPeriod: 30s
evictionSoft:
  memory.available: 1024Mi
  nodefs.available: 10Gi
  imagefs.available: 10Gi
evictionHard:
  memory.available: 512Mi
  nodefs.available: 5Gi
  imagefs.available: 5Gi
evictionSoftGracePeriod:
   memory.available: 30s
fileCheckFrequency: 10s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 60s
imageMinimumGCAge: 129600s
kind: KubeletConfiguration
nodeStatusReportFrequency: 60s
maxPods: 110
nodeStatusUpdateFrequency: 10s
rotateCertificates: true
runtimeRequestTimeout: 30s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 15m
syncFrequency: 60s
volumeStatsAggPeriod: 60s

已存在节点重启kubelet进程

[root@k8s-master kubelet]# systemctl daemon-reload
[root@k8s-master kubelet]# systemctl restart kubelet
[root@k8s-master kubelet]# systemctl status kubelet

使用kubeadm命令更新node配置

前面的操作都是手动去更新/var/lib/kubelet/config.yaml，稍微有些繁琐，当然配合ansible自动化工具一键替换减轻工作量。而此处提供另外一种方式，那就是使用kubeadm命令来更新配置

1.完成kube-system空间下kubelet的configmap配置修改

2.执行kubeadm upgrade node来更新当前节点配置

[root@k8s-master kubeadm]# kubeadm upgrade node
[upgrade] Reading configuration from the cluster...
[upgrade] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade] Upgrading your Static Pod-hosted control plane instance to version "v1.18.9"...
Static pod: kube-apiserver-k8s-master hash: 192e6dd71a900f304a16a37c11bc254f
Static pod: kube-controller-manager-k8s-master hash: 356740264271957bc1f4e25572eff010
Static pod: kube-scheduler-k8s-master hash: 119b9a7e2b8d8fc97be3274e089bc788
[upgrade/etcd] Upgrading to TLS for etcd
[upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.9" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests965007108"
W0219 14:50:45.886003   56773 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Current and new manifests of kube-apiserver are equal, skipping upgrade
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Current and new manifests of kube-controller-manager are equal, skipping upgrade
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Current and new manifests of kube-scheduler are equal, skipping upgrade
[upgrade] The control plane instance for this node was successfully updated!
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade] The configuration for this node was successfully updated!
[upgrade] Now you should go ahead and upgrade the kubelet package using your package manager.
[root@k8s-master kubeadm]# systemctl daemon-reload
[root@k8s-master kubeadm]# systemctl restart kubelet

从上面输出可以看到当前节点的/var/lib/kubelet/config.yaml已更新，之后需要步骤重载并重启kubelet服务即可，其他节点也是一样执行kubeadm upgrade node后再重载并重启kubelet服务

[root@k8s-node-01 ~]# kubeadm upgrade node
[upgrade] Reading configuration from the cluster...
[upgrade] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade] Skipping phase. Not a control plane node.
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[upgrade] The configuration for this node was successfully updated!
[upgrade] Now you should go ahead and upgrade the kubelet package using your package manager.
[root@k8s-node-01 ~]# systemctl daemon-reload
[root@k8s-node-01 ~]# systemctl restart kubelet

参考文档：

正文完
kubernetes
2020-12-18
 
xadocker
版权声明：本站原创文章，由 xadocker 2020-12-18发表，共计16439字。
转载说明：除特殊说明外本站文章皆由CC-4.0协议发布，转载请注明出处。
Prometheus-operator对etcd的监控
使用Thanos来扩展prometheus的高可用
k8s prometheus-operator
K8s 持久化存储-nfs
评论（没有评论）