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