K8S权威指南学习之token认证与K8S集群升级
-
kube-apiserver基于token的认证机制
kubenetes除了基于ca证书的认证方式，也提供了基于http token的认证方式。各客户端组件与api server之间的通信方式仍然采用https，但不采用ca数字证书。这种机制与ca证书相比，安全性很低，在生产不建议使用。
采用基于HTTP Token的简单认证方式时，APIServer对外暴露HTTPS端口，客户端携带Token来完成认证过程。 需要说明的是， kubectl命令行工具比较特殊， 它同时支持CA 证书和简单认证 两种方式与 API Server通信， 其他客户端组件只能配置基于 CA 证书的认证方式或者非安全方式与 API Server通信。
基于Token认证的配置过程如下：
-
创建包括用户名，密码和uid的文件token_auth_file,将其放置在合适的目录下，例如/etc/kubernetes目录。需要注意的是，这是一个纯文本的文件，用户名，密码都是明文。较为简单。
2.设置kube-apiserver的启动参数，"—token-auth-file"，使用上述文件提供安全认证，然后重启Api server服务。
3.用curl客户端工具通过token访问API server：
-
-
使用私有镜像库的相关配置
在kubernetes集群中，容器应用都是基于镜像启动的，在私有云环境下建议搭建私有镜像库进行镜像的管理。在公有云中可以直接使用云服务商提供的镜像库。
私有镜像选择：
- docker提供的Registry镜像库，详细说明请参考官网的说明。
- Harbor镜像仓库，可以去官网看相关说明，或者看一看harbor权威指南这一书。
此外，kubernetes对于创建pod需要使用一个名为"pause"的镜像，tag名为"k8s.gcr.io/pause:3.2",默认从镜像库k8s.gcr.io下载，在私有云环境中可以将其上传到私有镜像库，并修改kubelet的启动参数—pod-infra-container-image，将其设置为使用镜像库的镜像名称，例如：
--pod-infra-container-image=<my-private-registry>/pause:3.2
-
二进制文件升级
在进行Kubernetes的版本升级之前，需要考虑不中断正在运行的业务容器的灰度升级方案。 常见的做法是：先更新Master上Kubernetes服务的版本， 再逐个或批量更新集群中的Node上Kubernetes服务的版本。 更新Node的Kubernetes服务的步骤通常包括：先隔离一个或多个Node的业务流量， 等待这些Node上运行的Pod将当前任务全部执行完成后， 停掉业务应用（Pod ）， 再更新这些Node上的kubelet和kube-proxy版本 ， 更新完成后重启业务应用（Pod ），并将业务流量导人新启动的这些Node上，再隔离剩余的Node,逐步完成Node的版本升级， 最终完成整个集群的Kubernetes版本升级。
同时， 应该考虑高版本的Master对低版本的Node的兼容性问题。 高版本的Master 通常可以管理低版本的Node，但版本差异不应过大， 以免某些功能或API版本被弃用后，低版本的Node无法运行。
- 通过官网获取最新版本的二进制包kubernetes.tar.gz， 解压后提取服务的二进制文件。
- 更新Master的kube-apiserver、kube-controller-manager、kube-scheduler服务的二进制文件和相关配置（在需要修改时更新）并 重启服务。
- 逐个或批量隔离Node，等待其上运行的全部容器工作完成后停掉Pod，更新kubelet、kube-proxy服务文件和相关配置（在需要修改时更新）， 然后重启这两个服务。
-
使用kubeadm进行集群升级
kubeadm提供了upgrade 命令用于对kubeadm安装的Kubemetes集群进行升级。这一功能提供了从 1.10 到 1.1 l 、从 1.1 l 到 1.12 、从 1.12 至 1.13 及从 1.13 到 1.14 升级的能力， 本节以从 1.13 到 1.14 升级为例进行说明。
升级之前需要注意：
虽然kubeadm的升级不会触及工作负载，但还是要在升级之前做好备份；
升级过程中可能会因为pod的变化而造成容器重启。
以centos7为例，首先需要升级的是kubeadm：
yum install -y kubeadm-1.14.0 -disableexcludes=Kubernetes
然后再查看版本既可
接下来查看kubeadm的升级计划
kubeadm upgrade plan
