k8s最新版本（k8s-v1.15升级v1.16-已解决）

本文目录

• k8s-v1.15升级v1.16-已解决
• 在K8S中使用Local持久卷
• 二进制安装K8S（基于1.19.16版本）
• k8s系列02-kubeadm部署flannel网络的k8s集群
• mac安装k8s
• k8s 1.14版本证书过期问题解决
• k8s1.5版本支持创建deployment吗

k8s-v1.15升级v1.16-已解决

kubernetes版本的升级主要是升级kubeadm、kubectl和kubelet，升级应遵循以下原则：

1、apiserver保护版本最大，其它功能最多比apiserver小一个小版本号。

2、不能跨小版本升级。

0、使用下列命令列出可用版本

yum list --showduplicates kubeadm --disableexcludes=kubernetes

操作系统CentOS7，这次升级从 1.15.0 升级到 1.16.0。

1、升级kubeadm

yum install -y kubeadm-1.16.0-0 --disableexcludes=kubernetes

kubectl drain k8s-master --ignore-daemonsets --force

kubeadm upgrade plan

kubeadm upgrade apply v1.16.0

kubectl uncordon k8s-master

yum install -y kubelet-1.16.0-0 kubectl-1.16.0-0 --disableexcludes=kubernetes

systemctl daemon-reload

systemctl restart kubelet

2、k8s-master升级后看到k8s-master处于NotReady状态，查看日志:journalctl -f -u kubelet，服务一直提示cni网络组件有问题

# kubectl get nodes

NAME        STATUS    ROLES    AGE    VERSION

k8s-master  NotReady  master  385d  v1.16.0

k8s-node1    Ready      node    385d  v1.15.0

k8s-node2    Ready      node    20h    v1.15.0

journalctl -f -u kubelet

3、删除原有flannel重新创建下试试：

***隐藏网址***

##删除可能会报错：

kubectl get DaemonSet -n kube-system

##删除里面的关于flannel的DaemonSet：

kubectl delete XXX -n kube-system

***隐藏网址***

clusterrole.rbac.authorization.k8s.io/flannel created

clusterrolebinding.rbac.authorization.k8s.io/flannel created

serviceaccount/flannel created

configmap/kube-flannel-cfg created

unable to recognize "kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

unable to recognize "kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

unable to recognize "kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

unable to recognize "kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

unable to recognize "kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"

4、换个flannel链接试试：

***隐藏网址***

podsecuritypolicy.policy/psp.flannel.unprivileged created

clusterrole.rbac.authorization.k8s.io/flannel configured

clusterrolebinding.rbac.authorization.k8s.io/flannel unchanged

serviceaccount/flannel unchanged

configmap/kube-flannel-cfg unchanged

daemonset.apps/kube-flannel-ds-amd64 created

daemonset.apps/kube-flannel-ds-arm64 created

daemonset.apps/kube-flannel-ds-arm created

daemonset.apps/kube-flannel-ds-ppc64le created

daemonset.apps/kube-flannel-ds-s390x created

5、我们查看k8s-master已经变成Ready状态

# kubectl get nodes

NAME        STATUS  ROLES    AGE    VERSION

k8s-master  Ready    master  385d  v1.16.0

k8s-node1    Ready    node    385d  v1.15.0

k8s-node2    Ready    node    20h    v1.15.0

6、升级业务节点（同样适用于剩余的其它控制节点）

yum install -y kubeadm-1.16.0-0 --disableexcludes=kubernetes

#在master节点执行

kubectl drain k8s-node-a --ignore-daemonsets --force

kubeadm upgrade node

yum install -y kubelet-1.16.0-0 kubectl-1.16.0-0 --disableexcludes=kubernetes

systemctl daemon-reload

systemctl restart kubelet

#在master节点执行

kubectl uncordon k8s-node-a

在K8S中使用Local持久卷

由于容器本身是非持久化的，因此需要解决在容器中运行应用程序遇到的一些问题。首先，当容器崩溃时，kubelet将重新启动容器，但是写入容器的文件将会丢失，容器将会以镜像的初始状态重新开始；第二，在通过一个Pod中一起运行的容器，通常需要共享容器之间一些文件。Kubernetes通过卷解决上述的两个问题。

在Docker有卷的概念卷，但Docker中存储卷只是磁盘的或另一个容器中的目录，并没有对其生命周期进行管理。Kubernetes的存储卷有自己的生命周期，它的生命周期与使用的它Pod生命周期一致。因此，相比于在Pod中运行的容器来说，存储卷的存在时间会比的其中的任何容器都长，并且在容器重新启动时会保留数据。当然，当Pod停止存在时，存储卷也将不再存在。在Kubernetes支持多种类型的卷，而Pod可以同时使用各种类型和任意数量的存储卷。在Pod中通过指定下面的字段来使用存储卷：

PV是系统管理员设置的存储，它是群集的一部分，是一种资源，所以它有独立于Pod的生命周期。
PVC是用户存储的请求。它与Pod相似，Pod消耗节点的CPU和内存资源，PVC则消耗PV资源，可以生命特定的容量大小和访问模式。

PV和PVC遵循如下的生命周期管理

PV有两种配置方式：静态或动态

要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass 准入控制器 。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。有关 API server 命令行标志的更多信息，请检查 kube-apiserver 文档。

一旦用户创建或已经创建了具有特定存储量的 PersistentVolumeClaim 以及某些访问模式。Kubernetes控制器会监视到新的 PVC，并寻找匹配的 PV，并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则控制器会始终将该 PV 绑定到 PVC。总之，用户总会得到他们所请求的存储，但是容量可能超出请求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射。

如果没有匹配的PV，PVC将无限期地保持未绑定状态。随着匹配PV的可用，PVC将被绑定。例如，配置了许多 50Gi PV的集群将不会匹配请求 100Gi 的PVC。将100Gi PV 添加到群集时，则可以绑定到该 PVC。

Pod 使用PVC作为卷。集群检查PVC以查找绑定的卷并为集群挂载该卷。对于支持多种访问模式的卷，用户指定在使用声明作为容器中的卷时所需的模式（读写、只读）。

用户生命了PVC，并且该PVC是绑定的，则只要用户需要，绑定的 PV 就属于该用户。用户通过在 Pod 的 volume 配置中包含persistentVolumeClaim来调度 Pod 并访问用户声明的 PV。

K8S支持的卷类型很多，主要分为分布式文件系统、ConfigMap和本地文件系统这几种，其中本地文件系统支持：hostPath和local（从1.11开始出了Beta版本，编写本文时目前K8S最新版本是1.13了）。

在我们目前项目的实际开发中，我们常用两种卷挂载模式：

但是对于使用到本地磁盘来存储数据时，hostPath往往不太适合我们了，虽然它能够让Pod使用本地存储，将Node文件系统中的文件或者目录挂载到容器内，但是在这种应用场景，hostPath并不适合生产环境使用，主要原因如下：

当然hostPath还有其他的缺点，由于以上这两个关键的缺陷，在真正需要持久化数据存储的场景，我们不得不考虑local存储卷了。

Local PV是从kuberntes 1.10开始引入，本质目的是为了解决hostPath的缺陷。通过PV控制器与Scheduler的结合，会对local PV做针对性的逻辑处理，从而，让Pod在多次调度时，能够调度到同一个Node上。

首先，我们要准备好K8S环境，检查一下K8S中的节点。

现在登录到节点10.25.68.239上，然后手工创建一个目录，我们将后在后面创建的local PV绑定到这个目录中。

创建local的Storage Class

查看一下创建的storage class

创建PV：

查看一下pv情况

创建PVC

PVC将会一直处于Pending状态直到我们创建一个Pod使用它。

创建一个deployment使用这个pvc。

pvc现在绑定到对应的pv上面了。

查看pod被调度的节点，可以看到这个pod是会被调度到PV所在的Node：

我们再次登录到10.25.68.239，在/data/pv下生成index.html文件

检查一下index.html文件的服务

Local持久卷基本具备了hostPath的绑定本地文件系统目录的能力和方便性，同时自动具备调度到指定节点的能力，并且可以对持久卷进行管理。
唯一的问题在于，我们还需要手工去对应的节点创建对应的目录和删除对应的目录，这需要结合我们的应用系统来进行统一的设计和管理。
总得来说，对于状态应用程序的部署来说，Local持久卷能够提供分布式存储无法提供的高性能，同时具备了一定的调度的灵活性，是一个不错的选择。

二进制安装K8S（基于1.19.16版本）

通过kubeadmin安装K8S集群可以做到快速部署，但是如果需要调整K8S各个组件及服务的安全配置，高可用模式，最好通过二进制模式进行K8S的安装
生产环境K8S Master节点最好在3个节点以上，且配置不低于4核16g
生产环境：确保Master高可用，启用安全访问机制

PS：

服务器节点只是起名字，与是否为k8s-master或k8s-node无关，可根据需要增加或删减测试用例的数量，如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192.168.100.100
node1 192.168.100.101
node2 192.168.100.102

注：本节中创建的证书为部署流程全过程证书，测试用例为openssl生成证书，cfssl生成证书需要参考cfssl生成k8s证书，并在对应配置文件的相关证书位置替换对应证书

在配置文件中需要在设置Master服务的全部域名和IP地址，包括：

参数解析

配置文件详解：

分发配置文件

配置文件详解：

配置详解

分发配置文件

分发配置文件

在三个kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虚拟IP地址）192.168.100.200作为Master的唯一入口地址，供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。
接下来在主机master（192.168.100.100）和主机node1（192.168.100.101）中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP的高可用

准备 HAProxy 的配置文件 haproxy.cfg

参数说明：

分发配置文件

在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署HAProxy，并将配置文件挂载到容器的/usr/local/etc/haproxy下

访问192.168.100.100:8888/stats，192.168.100.101:8888/stats

keepalived用于维护VIP地址的高可用，同样在master和node1中部署

主节点配置文件

子节点配置文件

参数解析

主节点和子节点配置异同

健康检查脚本
keeplived需要持续监控HAProxy的运行状态，在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本，定期运行监控
脚本内容如下：

分发脚本

在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署keeplived，并将配置文件挂载到容器的/container/service/keepalived/assets下，将脚本挂载到容器的/usr/bin下

检查ens33网卡是否存在keeplived VIP地址

检测keeplived是否进行转发

注：master集群已经配置完毕，后续需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，还需要部署CNI网络插件、DNS插件等
之前已经在master，node1，node2中部署了docker，接下来需要部署其他服务组件，本节部署kubelet组件

参数说明

参数说明

参数说明

当前显示所有node为NOT READY，需要部署完网络插件才可使用
为方便使用kubectl

k8s系列02-kubeadm部署flannel网络的k8s集群

本文主要在centos7系统上基于 docker 和 flannel 组件部署 v1.23.6 版本的k8s原生集群，由于集群主要用于自己平时学习和测试使用，加上资源有限，暂不涉及高可用部署。

此前写的一些关于k8s基础知识和集群搭建的一些 方案 ，有需要的同学可以看一下。

机器均为8C8G的虚拟机，硬盘为100G。

同一个k8s集群内的所有节点需要确保 mac 地址和 product_uuid 均唯一，开始集群初始化之前需要检查相关信息

如果k8s集群的节点有多个网卡，确保每个节点能通过正确的网卡互联访问

这里可以根据自己的习惯选择ntp或者是chrony同步均可，同步的时间源服务器可以选择阿里云的 ntp1.aliyun.com 或者是国家时间中心的 ntp.ntsc.ac.cn 。

k8s集群之间通信和服务暴露需要使用较多端口，为了方便，直接禁用防火墙

这里主要是需要配置内核加载 br_netfilter 和 iptables 放行 ipv6 和 ipv4 的流量，确保集群内的容器能够正常通信。

虽然新版本的k8s已经支持双栈网络，但是本次的集群部署过程并不涉及IPv6网络的通信，因此关闭IPv6网络支持

IPVS是专门设计用来应对负载均衡场景的组件， kube-proxy 中的 IPVS 实现 通过减少对 iptables 的使用来增加可扩展性。在 iptables 输入链中不使用 PREROUTING，而是创建一个假的接口，叫做 kube-ipvs0，当k8s集群中的负载均衡配置变多的时候，IPVS能实现比iptables更高效的转发性能。

详细的官方文档可以参考 这里 ，由于在刚发布的1.24版本中移除了 docker-shim ，因此安装的 版本≥1.24 的时候需要注意 容器运行时 的选择。这里我们安装的版本低于1.24，因此我们继续使用docker。

docker的具体安装可以参考我之前写的 这篇文章 ，这里不做赘述。

CentOS7使用的是 systemd 来初始化系统并管理进程，初始化进程会生成并使用一个 root 控制组 ( cgroup ), 并充当 cgroup 管理器。 Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup 。 我们也可以配置 容器运行时 和 kubelet 使用 cgroupfs 。 连同 systemd 一起使用 cgroupfs 意味着将有两个不同的 cgroup 管理器 。而当一个系统中同时存在cgroupfs和systemd两者时，容易变得不稳定，因此最好更改设置，令容器运行时和 kubelet 使用 systemd 作为 cgroup 驱动，以此使系统更为稳定。 对于 Docker, 需要设置 native.cgroupdriver=systemd 参数。

k8s官方有 详细的文档 介绍了如何设置kubelet的 cgroup driver ，需要特别注意的是，在1.22版本开始，如果没有手动设置kubelet的cgroup driver，那么默认会设置为systemd

一个比较简单的指定kubelet的 cgroup driver 的方法就是在 kubeadm-config.yaml 加入 cgroupDriver 字段

我们可以直接查看configmaps来查看初始化之后集群的kubeadm-config配置。

当然因为我们需要安装的版本高于1.22.0并且使用的就是systemd，因此可以不用再重复配置。

kube三件套就是 kubeadm 、 kubelet 和 kubectl ，三者的具体功能和作用如下：

需要注意的是：

CentOS7的安装比较简单，我们直接使用官方提供的 yum 源即可。需要注意的是这里需要设置 selinux 的状态，但是前面我们已经关闭了selinux，因此这里略过这步。

在集群中所有节点都执行完上面的三点操作之后，我们就可以开始创建k8s集群了。因为我们这次不涉及高可用部署，因此初始化的时候直接在我们的目标master节点上面操作即可。

此时我们再查看对应的配置文件中的镜像版本，就会发现已经变成了对应阿里云镜像源的版本

当我们看到下面这个输出结果的时候，我们的集群就算是初始化成功了。

刚初始化成功之后，我们还没办法马上查看k8s集群信息，需要配置kubeconfig相关参数才能正常使用kubectl连接apiserver读取集群信息。

配置完成后，我们再执行相关命令就可以查看集群的信息了。

这时候我们还需要继续添加剩下的两个节点作为worker节点运行负载，直接在剩下的节点上面运行集群初始化成功时输出的命令就可以成功加入集群：

如果不小心没保存初始化成功的输出信息也没有关系，我们可以使用kubectl工具查看或者生成token

添加完成之后我们再查看集群的节点可以发现这时候已经多了两个node，但是此时节点的状态还是 NotReady ，接下来就需要部署CNI了。

flannel 应该是众多开源的CNI插件中入门门槛最低的CNI之一了，部署简单，原理易懂，且相关的文档在网络上也非常丰富。

针对 kube-flannel.yml 文件，我们需要修改一些 参数 以适配我们的集群：

修改完成之后我们直接部署即可

集群部署完成之后我们在k8s集群中部署一个nginx测试一下是否能够正常工作。首先我们创建一个名为 nginx-quic 的命名空间（ namespace ），然后在这个命名空间内创建一个名为 nginx-quic-deployment 的 deployment 用来部署pod，最后再创建一个 service 用来暴露服务，这里我们先使用 nodeport 的方式暴露端口方便测试。

部署完成后我们直接查看状态

最后我们进行测试，这个nginx-quic的镜像默认情况下会返回在nginx容器中获得的用户请求的IP和端口

mac安装k8s

安装k8s大致有2种方式，minikube和Docker Desktop上，本文采用后者，前者见 minikube安装k8s

***隐藏网址***

如果安装成功，则会显示 kubernetes running

获取到token如下图

***隐藏网址***

输入上一步获取的token, 验证并登陆。

登录成功如下图

k8s 1.14版本证书过期问题解决

说起来，都是泪，从三年前和这个问题作斗争，证书过期和自动续期这个大问题，始终是一个心头的伤。
现在要想到一刀切的方案，还是自己更改Kubeadm源码，全部改成100年，最洒脱。
但，如果线上已运行了这些东东，且是10年1年证书过期的都有，那啷个弄嘛？

先用如下命令，看看k8s的哪些证书何时到期

输出pki下的证书情况：

输出/etc/kubernetes下的证书情况

cp -R /etc/kubernetes /etc/kubernetes$(date "+%Y%m%d")

又或者一条命令搞定
kubeadm init phase kubeconfig all
这里有个注意的细节，在使用kubeadm命令之前，它会到外网查找此K8s集群的版本信息，如果我们的机器是纯企业内网，不能访问外面，这里就会卡住。
BUT，还是可以离线进行的。
先从本集群生成一个config view类型文件。
kubeadm config view 》 kubeadm.conf
然后，在之后生成证书时，加上这个文件作为--config参数即可。如
kubeadm alpha phase kubeconfig scheduler --config kubeadm.conf
(上面是kueadm 1.10版本的命令，新版本已从alpha转正式命令，-h可找出来)

如果生疏了，可能看看help命令

1，仍然先备份哟，备份使得万年船~~
cp -R /etc/kubernetes /etc/kubernetes$(date "+%Y%m%d")
2，先将要过期的证书作更名

3，生成k8s的config view，然后使用kubeadm生成新的证书对

4，依次升级完其它几个要过期的证书，包括与etcd连接的证书对。
5，注意，有三个根证书对，是20年过期的，我没有更新（关键我不清楚更新之后，会发生什么事）。

6，根据不同版本，查看证书过期的命令还不一样呢，最好再作个重复记录。
查看/etc/kubernetes/pki目录证书过期

查看/etc/kubernetes/目录下的几个conf里的证书过期

k8s1.5版本支持创建deployment吗

• 看报错是不支持，但不像是版本太老，是你文件里的api写的不对，你说的报错也太模糊，起码把yaml和报错截图贴出来。

• k8s1.5版本  yaml 用如下apiVersion

  apiVersion: extensions/v1beta1