Kubernetes集群的组件众多,要部署一套符合生产环境的集群不是一件容易的事。好在随着社区的快速发展,特别是在它成为事实上的容器编排标准之后,基本全部的主流云平台都彻底支持Kubernetes,或把它做为核心的云解决方案。同时,本地部署也出现了各种成熟的主动化解决方案,特别是Kubeadm,在最新的1.13版本已经官方GA了,也就是彻底能够用在生产环境中了。这些云服务或自动化工具都大大减小了Kubernetes的部署难度,让运维力量不足的小型公司也能快速的搭建出可用的Kubernetes生产环境。html
Kubernetes官方文档中,总共列出了5大类,不下30种的Kubernetes安装方式。不说别的,单从数量来讲,就能够看出当前Kubernetes生态的包容性和目前其余各种平台对它的技术支持有多强。文档中把部署方案分为如下几类:node
能够理解为单机版的Kubernetes,很是适合入门Kubernetes学习或测试使用。表明的解决方案为Minikube。web
这三种方式能够放在一块说,他们都是基于云服务商提供的解决方案,区别以下:segmentfault
Hosted方式是指云服务商搭建的一套公共的Kubernetes,用户直接使用就行了,集群的搭建、管理、运维等操做所有都由云服务商提供,用户只要专一于本身的应用开发,不用关注集群的运维。这种解决方案特别适合小开发团队或小型公司,不只省去了自有硬件的维护成本,连系统运维人员均可以不用了。api
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。less
Custom安装方式顾名思义,是彻底由用户本身安装维护Kubernetes,集群服务器和部署、配置、运维都由用户本身完成。这种方案灵活度最高,相对的,付出的硬件成本和部署、维护成本也最高。这里的服务器能够是相似EC二、ECS这种云主机,也能够是本地服务器、虚拟机等,甚至基于ARM的嵌入式硬件目前也能运行Kubernetes。Custom方式也是通常大公司在生产环境使用Kubernetes的最佳选择,一方面,大公司运维、开发团队人员完善,能够独立部署和运维Kubernetes集群,而且还能够根据本身的需求进行二开,整合Kubernetes容器部署、日志、监控等,打造出适合公司业务的容器平台。另外一方面,不少公司考虑容器化业务的出发点之一就是能够优化公司现有的硬件资源,把原来跑物理服务器或虚拟机的业务迁移到容器平台上来,以提升自有硬件资源利用率及节省成本。现阶段,Custom部署方式除了一步步编译并部署、配置各组件,还能够经过Kubeadmin简单快速的部署出生产可用的集群。运维
虽然官网列出的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主要作了这些事:
因此,minikube其实是基于Kubeadm工具来部署Kubernetes的,咱们经过minikube ssh命令能够进入部署的虚拟机中,看下里面在跑的容器:
有木有看到不少熟悉的身影,有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 <none> 80:31534/TCP 3s kubernetes ClusterIP 10.96.0.1 <none> 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部署一个多节点集群。