Kubernetes的几种主流部署方式01-minikube部署
综述
Kubernetes集群的组件众多，要部署一套符合生产环境的集群不是一件容易的事。好在随着社区的快速发展，特别是在它成为事实上的容器编排标准以后，基本所有的主流云平台都完全支持Kubernetes，或把它作为核心的云解决方案。同时，本地部署也出现了各类成熟的主动化解决方案，特别是Kubeadm，在最新的1.13版本已经官方GA了，也就是完全可以用在生产环境中了。这些云服务或自动化工具都大大减少了Kubernetes的部署难度，让运维力量不足的小型公司也能快速的搭建出可用的Kubernetes生产环境。
Kubernetes部署方案对比
Kubernetes官方文档中，总共列出了5大类，不下30种的Kubernetes安装方式。不说别的，单从数量来说，就可以看出当前Kubernetes生态的包容性和目前其他各类平台对它的技术支持有多强。文档中把部署方案分为以下几类：
- Local-machine Solutions
可以理解为单机版的Kubernetes，非常适合入门Kubernetes学习或测试使用。代表的解决方案为Minikube。
- Hosted Solutions
- Turnkey – Cloud Solutions
- Turnkey – On-Premises Solutions
这三种方式可以放在一块说，他们都是基于云服务商提供的解决方案，区别如下：
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。
- Custom Solutions
Custom安装方式顾名思义，是完全由用户自己安装维护Kubernetes，集群服务器和部署、配置、运维都由用户自己完成。这种方案灵活度最高，相对的，付出的硬件成本和部署、维护成本也最高。这里的服务器可以是类似EC2、ECS这种云主机，也可以是本地服务器、虚拟机等，甚至基于ARM的嵌入式硬件目前也能运行Kubernetes。Custom方式也是一般大公司在生产环境使用Kubernetes的最佳选择，一方面，大公司运维、开发团队人员完善，可以独立部署和运维Kubernetes集群，并且还可以根据自己的需求进行二开，整合Kubernetes容器部署、日志、监控等，打造出适合公司业务的容器平台。另一方面，很多公司考虑容器化业务的出发点之一就是可以优化公司现有的硬件资源，把原来跑物理服务器或虚拟机的业务迁移到容器平台上来，以提高自有硬件资源利用率及节省成本。现阶段，Custom部署方式除了一步步编译并部署、配置各组件，还可以通过Kubeadmin简单快速的部署出生产可用的集群。
虽然官网列出的Kubernetes部署方式很多，但也不用被这么多种部署方式搞糊涂了。所有Kubernetes集群，都少不了关键的基础组件。（参考Kubernetes概念与术语中的组件部分），不同的部署方式，无非是这些组件由云服务商部署好了，用户只要使用集群就好（Host 或 Turnkey方案），或着被做成容器运行以方便快速部署和管理（Minicube、Kubeadm等）。
Minikube 部署
简介
Minikube是由Kubernetes社区维护的单机版的Kubernetes集群，支持macOS, Linux, and Windows等多种操作系统平台，使用最新的官方stable版本，并支持Kubernetes的大部分功能，从基础的容器编排管理，到高级特性如负载均衡、Ingress，权限控制等。非常适合作为Kubernetes入门，或开发测试环境使用。Minikube实际是跑在本地的虚拟机中的，所以，需要先安装一套Hypervisor。这里以VirtualBox为例。
部署步骤
环境
- OS：macOS Mojave
- Hypervisor：VirtualBox 6.0
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的虚拟机，并在虚拟机中安装了Docker容器运行时。（实际就是Docker-machine）
- 下载了Kubeadm与Kubelet工具
- 通过Kubeadm部署Kubernetes集群
- 进行各组件间访问授权、健康检查等工作
- 在用户操作系统安装并配置kubectl
所以，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一致。
开启Kubernetes dashboard
可以通过minikube dashboard命令直接开启dashboard
macOS会自动在你的默认浏览器打开，可以通过web查看和管理集群了。
小结
本文介绍了Kubernetes不同部署方式的区别，同时详细说明了minikube这个单节点Kubernetes工具的部署步骤、以及对部署后的集群做了简单测试。通过上面的部署分析可以看出，minikube的核心实际还是依靠kubeadm这个工具来部署集群的，后面的文章会介绍如何用Kubeadm部署一个多节点集群。