网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

kubernetes 集群升级至 v1.12 需要注意的几个问题

2020-06-10 11:37:56 admin 0

最近我们生产环境的集群开始升级至 v1.12 版本了，之前的版本是 v1.8，由于跨了多个版本，风险还是比较大的，官方的建议也是一个一个版本升级，k8s
每三个月出一个版本，集群上了规模后升级太麻烦，鉴于我们真正使用 k8s 中的功能还是比较少的，耦合性没有那么大，所以风险还是相对可控，测试环境运行
v1.12 一段时间后发现问题不大，于是开始升级。此处记录几个升级过程要注意的问题：

### 1、注意 k8s 中 resource version 的变化

k8s 中许多 resouce 都是随着 k8s 的版本变化而变化的，例如，statefulset 在 v1.8 版本中 apiVersion 是
apps/v1beta1，在 v1.12 中变为了 apps/v1。k8s 有接口可以获取到当前版本所有的 OpenAPI ：

image.png

参考文档：[The Kubernetes
API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/)

虽然 k8s 中 resource version 都是向下兼容的，但是在升级完成后尽量使用当前版本的 resource version 避免不必要的麻烦。

### 2、kubelet 配置文件格式

v1.8 中 kubelet 的配置是在 /etc/kubernetes/kubelet 文件中的 KUBELET_ARGS 后面指定，但是在 v1.12
中开始使用 config.yaml 文件，即所有的配置都可以放在 yaml 文件中，由于配置是兼容的，所以暂时也可以继续用以前的方式，其中有些参数仅支持在
config.yaml 文件中指定。

config.yaml 文件的官方说明：[Set Kubelet parameters via a config
file](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-
file/)

一个例子：

apiVersion : kubelet.config.k8s.io/v1beta1
    kind: KubeletConfiguration
    address: 0.0.0.0
    - pods
    eventBurst: 10
    eventRecordQPS: 5
    evictionHard:
      imagefs.available: 15%
      memory.available: 100Mi
      nodefs.available: 10%
      nodefs.inodesFree: 5%
    evictionPressureTransitionPeriod: 5m0s
    failSwapOn: true
    fileCheckFrequency: 20s
    healthzBindAddress: 127.0.0.1
    healthzPort: 10248
    httpCheckFrequency: 20s
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80
    imageMinimumGCAge: 2m0s
    maxOpenFiles: 1000000
    maxPods: 110
    nodeLeaseDurationSeconds: 40
    nodeStatusUpdateFrequency: 10s
    oomScoreAdj: -999
    podPidsLimit: -1
    port: 10250
    staticPodPath: /etc/kubernetes/manifests

将 kubelet 配置文件中的 LOG_LEVEL 参数改为大于等于 5 可以看到 config.yaml 中配置的定义，以方便排查问题：

image.png

对应的日志输出：

I0228 16:14:14.064292  191819 server.go:260] KubeletConfiguration: 
    config.KubeletConfiguration {TypeMeta:v1.TypeMeta{Kind:"", 
    APIVersion:""}, StaticPodPath:"", Sync    
    Frequency:v1.Duration{Duration:60000000000}, 
    FileCheckFrequency:v1.Duration{Duration:20000000000},
    HTTPCheckFrequency:v1.Duration{Duration:20000000000}, 
    StaticPodURL:"", StaticPodURLHeader:map[string][]string(nil),
    Address:"0.0.0.0", Port:10250, 
    ...

> 注意：kubelet 配置文件中 ARGS 中定义的参数会覆盖 config.yaml 中的定义。

### 3、feature-gates 中功能的使用

v1.12 中 feature-gates 中许多功能默认为开启状态，部分功能的参数名称已经修改，实际遇到的有 `--experimental-
allowed-unsafe-sysctls` 改为了 `--allowed-unsafe-sysctls` 导致 kubelet
启动失败，其余参数需要根据实际场景选择，不必要的功能在配置文件中将其关闭。

k8s 各版本中的 Feature 列表以及是否启用状态可以在 [Feature
Gates](https://kubernetes.io/docs/reference/command-line-tools-
reference/feature-gates/) 中查看。

### 4、cadvisor 的使用

k8s 在 1.12 中将 cadvisor 从 kubelet 中移除了，若要使用 cadvisor，官方建议使用 DaemonSet
进行部署。由于我们一直从 cadvisor 获取容器的监控数据然后推送到自有的监控系统中进行展示，所以 cadvisor 还得继续使用。

这是官方推荐的 cadvisor 部署方法，[cAdvisor Kubernetes
Daemonset](https://github.com/google/cadvisor/blob/master/deploy/kubernetes/README.md)，其中用了
`k8s.gcr.io/cadvisor:v0.30.2` 镜像，在我们的测试环境中，该镜像无法启动，报错
`/sys/fs/cgroup/cpuacct,cpu: no such file or directory`, 经查 cadvisor v0.30.2
版本的镜像使用 cgroup v2，v2 版本中已经没有了 cpuacct subsystem，而 linux kernel 4.5 以上的版本才支持
cgroup v2，与我们的实际场景不太相符，最后测试发现 v0.28.0 的镜像可以正常使用。

由于要兼容之前的使用方式，cadvisor 在宿主机上需要启动 4194 端口，但是创建容器又要结合自身的网络方案，最终我们使用 hostnetwork
的方式部署。

apiVersion : apps/v1
    kind: DaemonSet
    metadata:
      name: cadvisor
      namespace: kube-system
      labels:
        app: cadvisor
    spec:
      selector:
        matchLabels:
          name: cadvisor
      template:
        metadata:
          labels:
            name: cadvisor
        spec:
          hostNetwork: true
          tolerations:
          - key: node-role.kubernetes.io/master
            effect: NoSchedule
            key: enabledDiskSchedule
            value: "true"
            effect: NoSchedule
          containers:
          - name: cadvisor
            image: k8s.gcr.io/cadvisor:v0.28.0
            imagePullPolicy: IfNotPresent
            volumeMounts:
            - name: rootfs
              mountPath: /rootfs
              readOnly: true
            - name: var-run
              mountPath: /var/run
              readOnly: false
            - name: sys
              mountPath: /sys
              readOnly: true
            - name: docker
              mountPath: /var/lib/docker
              readOnly: true
            ports:
              - name: http
                containerPort: 4194
                protocol: TCP
            readinessProbe:
              tcpSocket:
                port: 4194
              initialDelaySeconds: 5
              periodSeconds: 10
            args:
              - --housekeeping_interval=10s
              - --port=4194
          terminationGracePeriodSeconds: 30
          volumes:
          - name: rootfs
            hostPath:
              path: /
          - name: var-run
            hostPath:
              path: /var/run
          - name: sys
            hostPath:
              path: /sys
          - name: docker
            hostPath:
              path: /var/lib/docker

官方建议使用 kustomize 进行部署，kustomize 是 k8s 的一个配置管理工具，此处暂不详细解释。

> 注意：若集群中有打 taint 的宿主，需要在 yaml 文件中加上对应的 tolerations。

### 5、kube-apiserver 配置

v1.12 中 apiserver 也有许多参数已被废弃，以下仅为升级过程中遇到的一个 case：  
`--insecure-bind-address` 参数在 v1.12 被废弃了，在未来的版本中会被移除，去掉该参数后 apiserver 的 8080
仅对本机开放，若在 v1.12 apiserver 的配置文件中去掉该参数，请确保出本机外连接 apiserver 的服务使用的是 6443 端口，本机上的
kubectl 依然可以使用。

转载文章，原文链接： kubernetes 集群升级至 v1.12 需要注意的几个问题

关键字词集群 kubernetes

分享到：

上一篇：kubernets 中事件处理机制

下一篇：kubernets 中组件高可用的实现方式

如需留言，请登录，没有账号？请注册

0 条评论 0 人参与

网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

kubernetes 集群升级至 v1.12 需要注意的几个问题

admin 7个月前

admin 7个月前

admin 7个月前

admin 7个月前

龙行 7个月前

网站首页 返回列表 像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

kubernetes 集群升级至 v1.12 需要注意的几个问题

admin 官方 7个月前

admin 官方 7个月前

admin 官方 7个月前

admin 官方 7个月前

龙行 7个月前

网站首页返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

admin 7个月前

admin 7个月前

admin 7个月前

admin 7个月前