Kubernetes集群的组件众多,要部署一套符合生产环境的集群不是一件容易的事。好在随着社区的快速发展,特别是在它成为事实上的容器编排标准以后,基本所有的主流云平台都完全支持Kubernetes,或把它作为核心的云解决方案。同时,本地部署也出现了各类成熟的主动化解决方案,特别是Kubeadm,在最新的1.13版本已经官方GA了,也就是完全可以用在生产环境中了。这些云服务或自动化工具都大大减少了Kubernetes的部署难度,让运维力量不足的小型公司也能快速的搭建出可用的Kubernetes生产环境。
Kubernetes官方文档中,总共列出了5大类,不下30种的Kubernetes安装方式。不说别的,单从数量来说,就可以看出当前Kubernetes生态的包容性和目前其他各类平台对它的技术支持有多强。文档中把部署方案分为以下几类:
Hosted方式是指云服务商搭建的一套公共的Kubernetes,用户直接使用就好了,集群的搭建、管理、运维等操作全部都由云服务商提供,用户只要专注于自己的应用开发,不用关注集群的运维。这种解决方案特别适合小开发团队或小型公司,不仅省去了自有硬件的维护成本,连系统运维人员都可以不用了。
Turnkey–Cloud Solutions指云服务商帮忙搭建了Kubernetes Master节点,并负责维护其可用性,用户可以自定义Node节点加入集群,可以根据具体需求灵活并只用关注Node节点的维护
Turnkey–On-Premises Solutions方案是指包括Master节点和Node节点都由用户配置及维护,灵活性最高,但资源成本和运维成本也最高。
但不管上述哪种方式,云服务商都已经把Kubernetes做了一层包装,用户可以用简单的几个命令就可以部署Kubernetes集群,不需要从头开始一步步安装。
这三种不同的解决方案,阿里云的文档容器服务Kubernetes集群三种形态对比介绍的很清楚,可以对比着理解:
其中,Serverless对应Hosted Solution,托管版对应Turnkey – Cloud Solution,专有版对应Turnkey – On-Premises Solution。
虽然官网列出的Kubernetes部署方式很多,但也不用被这么多种部署方式搞糊涂了。所有Kubernetes集群,都少不了关键的基础组件。(参考Kubernetes概念与术语中的组件部分),不同的部署方式,无非是这些组件由云服务商部署好了,用户只要使用集群就好(Host 或 Turnkey方案),或着被做成容器运行以方便快速部署和管理(Minicube、Kubeadm等)。
Minikube是由Kubernetes社区维护的单机版的Kubernetes集群,支持macOS, Linux, and Windows等多种操作系统平台,使用最新的官方stable版本,并支持Kubernetes的大部分功能,从基础的容器编排管理,到高级特性如负载均衡、Ingress,权限控制等。非常适合作为Kubernetes入门,或开发测试环境使用。Minikube实际是跑在本地的虚拟机中的,所以,需要先安装一套Hypervisor。这里以VirtualBox为例。
Minikube的诞生的初衷就是为了能快速部署一个单机Kubernetes集群,所以,整个部署非常简单,就2条命令搞定:
brew cask install minikube
minikube start
brew cask install直接从官方下载了minikube程序,并加入环境变量。minikube start虽然只是一条命令,但其实执行了很多步骤,命令执行后输出如下:
$ minikube start
o minikube v0.35.0 on darwin (amd64)
> Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
- "minikube" IP address is 192.168.99.100
- Configuring Docker as the container runtime ...
- Preparing Kubernetes environment ...
@ Downloading kubeadm v1.13.4
@ Downloading kubelet v1.13.4
- Pulling images required by Kubernetes v1.13.4 ...
- Launching Kubernetes v1.13.4 using kubeadm ...
: Waiting for pods: apiserver proxy etcd scheduler controller addon-manager dns
- Configuring cluster permissions ...
- Verifying component health .....
+ kubectl is now configured to use "minikube"
= Done! Thank you for using minikube!
可以看到,minikube start主要做了这些事:
有木有看到很多熟悉的身影,有Master节点的组件kube-apiserver、kube-scheduler、kube-controller、etcd 容器,以及Node节点的kube-proxy容器,还有些附加的组件比如Coredns等。没错,Kubeadm实际就是把Kubernetes各个组件都容器化了(除了kubelet),而minikube再用虚拟机把它们都跑在一起。关于Kubeadm,下一篇文章会详细再介绍。
Minikube成功运行以后,就已经在用户操作系统中安装了kubectl,并将运行的集群变量设置为了minkube,可以通过*kubectl config view *命令查看当前的配置:
kubectl的作用集群已经被指定为minikube的虚拟机了。执行kubectl get node -o wide确认Kubernetes集群节点信息。
集群名称为minikube,只有一个master节点。
下面我们部署一个简单的goweb服务,该容器运行时会暴露8000端口,同时访问/info路径会显示容器的主机名。服务由3个容器实例构成,并且通过Nodeport方式暴露给用户。
// 创建一个名为goweb的Deployment,使用lingtony/goweb镜像,暴露8000端口,副本pod数为3
$ kubectl run goweb --image=lingtony/goweb --port=8000 --replicas=3
// 查看创建的对象,可以看到已经有3个pod在运行了
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
goweb 3/3 3 3 2m59s
$ kubectl get po
NAME READY STATUS RESTARTS AGE
goweb-8559474b8c-rphcs 1/1 Running 0 3m2s
goweb-8559474b8c-wzvsl 1/1 Running 0 3m2s
goweb-8559474b8c-xxtlz 1/1 Running 0 3m2s
// 创建svc,通过Nodeport方式暴露服务
$ kubectl expose deployment goweb --name=gowebsvc --port=80 --target-port=8000 --type=NodePort
service/gowebsvc exposed
// 查看svc,可以看到NodePort随机分配的端口为31543
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gowebsvc NodePort 10.108.29.53 80:31534/TCP 3s
kubernetes ClusterIP 10.96.0.1 443/TCP 7h58m
接下来,在用户操作系统就可以通过minikube虚拟机的ip地址:31543来访问这个gowebsvc了,gowebsvc会把80口的请求再负载均衡到实际的goweb pod上。更方便的,可以使用minikube server命令直接获取到svc的访问地址:
// 通过minikube server命令获取svc地址
$ minikube service gowebsvc --url
http://192.168.99.100:31534
// 测试访问一下
可以看到,每次的访问请求是都进入不同的pod,与kubectl get po命令所示的pod一致。
可以通过minikube dashboard命令直接开启dashboard
macOS会自动在你的默认浏览器打开,可以通过web查看和管理集群了。
本文介绍了Kubernetes不同部署方式的区别,同时详细说明了minikube这个单节点Kubernetes工具的部署步骤、以及对部署后的集群做了简单测试。通过上面的部署分析可以看出,minikube的核心实际还是依靠kubeadm这个工具来部署集群的,后面的文章会介绍如何用Kubeadm部署一个多节点集群。