kubernetes1.4 基础篇:Learn Kubernetes 1.4 by 6 steps
本教程受Kubernetes官方最新更新的文档所触发,之所以没有做单纯的翻译是因为如下几个原因:
- Kubernetes官方此教程基于minikube,个人对minikube可能有偏见,觉得像玩具。
- Minikube更新较慢,不久前试的仍然只是能模拟kubernetes1.3,kubeadm也出来了,只是用于教程的话完全可以取代。
- google的此教程提供了一个交互式的体验窗口,但是本来就不复杂的东西,就不想用它们的交互式的界面,感觉不真实,同时自己搭建可以先看什么就看什么,另外google目前提供的版本仍不是最新的。
- Kubernetes入门虽然不复杂,但是一般使用者第一个hello world的时间成本从接触到可用可能还是以天为计算单位,太浪费。但是确实作为对Kubernetes基本概念的理解的入门教程很不错,自己再重新看的时候也能温故而知新。从中糅出这几篇文章分享给大家,希望有所帮助。
Kubernetes基础
此系列教程中会着重于围绕Kubernetes集群编排相关的基本概念展开,同时通过容器化的应用如何在Kubernetes中部署/扩展/更新为主线而展开。我们将会学到:
- 将容器化的应用部署到集群上
- 扩展应用部署
- 更新容器化的应用程序版本
- 调试容器化的应用程序
Kubernetes是什么
Kubernetes是在整个计算机集群中对应用容器进行编排和执行的一个可以用于生产环境级别的开源平台。(了解更多内容 https://www.kubernetes.org.cn/kubernetes是什么)
Kubernetes能做什么
对于现代的web service,用于期待它应该是24×7的高可用,而开发者则期待能够每天都能对这些应用程序发布几个版本(虽然我没有这么想过)。容器化则能帮助打包应用程序完成这些目标,使得应用程序能够无宕机地平稳快速发布。Kubernetes则能够帮助做到剩下的事情。打完包的容器化应用运行在集群上需要做什么呢:
- 在哪个节点上执行
- 什么时候执行
- 使用那些resouce
- 如何在这个集群中调整这些resource
- ……
这些问题都需要进行考虑的,而现在kubernetes的编排和执行功能则为能为你排忧解难。而且Kubernetes不但是可以用于生产级别,而且还积累了google的多年容器化运行的经验,有前人踏坑的可用软件自然是大家竞相追逐的。
基本内容
本系列教程将以容器化的应用如何在Kubernetes集群上进行部署/更新/扩展按照如下六个步骤按序展开。
- Step 1. Create a Kubernetes cluster
- Step 2. Deploy an app
- Step 3. Explore your app
- Step 4. Expose your app publicly
- Step 5. Scale up your app
- Step 6. Update your app
组成要素
Kubernetes集群包含如下两种类型的资源:
类型 | 作用 |
---|---|
Master | 协调和操控集群 |
Node | 实际用于运行应用容器的”worker” |
集群构成
构成说明
Master的主要职责在于管理集群,协调集群上的所有活动,比如:
- 编排应用
- 维护应用状态
- 扩展应用
- 更新应用等
Node
Node就是一台在kubernetes集群中担任worker的VM或者物理机。在每个Node上都有一个kubelet,而Kubelet就是一个用于管理node和Master之间的沟通的agent。在node上需要安装docker,或者说用于管理容器操作的工具,因为kubernetes并不绑定docker,我们以前介绍过的rkt在kubernetes中也是支持的。而且明眼人都能看出来,rkt纯粹是google用于制衡docker的,rkt和kubernetes深度融合,但是是否能得到市场的认可这并不是一个纯粹技术的问题。
一个在生产环境中能够大体使用的kubernetes集群至少要有3个node。本来就是node的协调和编排,你就一个node,也非要用kubernetes,虽然可以任性,但是屠龙宝刀只用来裁墙纸多少会有大材小用的唏嘘。
Master
Master则用来管理集群。当你在kubernetes集群上部署应用的时候,你可能会需要Master启动某个应用容器。 Master在集群中协调用于启动此容器的node,而node使用kubernetes API和master进行通信(当然,用户也可以直接使用kubernetes API和集群进行交互)。
Kubernetes集群创建
Kubernetes集群可以被部署到物理机或者虚拟机上。可以使用minikube,但是本文将使用kubeadm方式创建一个3 node + 1 Master的集群。
构成
项番 | 类别 | host名 | IP |
---|---|---|---|
No.1 | Master | host31 | 192.168.32.31 |
No.2 | Node | host32 | 192.168.32.32 |
No.3 | Node | host33 | 192.168.32.33 |
No.4 | Node | host34 | 192.168.32.34 |
easypack_kubernetes.sh
K8S在1.4出来的时候向全世界宣布2条命令创建集群,在VPN的环境下,的确是这样,因为这些依赖关系1.4会根据需要自动的去pull,但是pull不到google_container的就这样被无比简单的一件事情堵在外面。本着利己利人的出发点,写了个脚本,放到了github上(https://github.com/liumiaocn/easypack/tree/master/k8s),脚本的使用基本上是sh easypack_kubernetes.sh MASTER来创建Master,sh easypack_kubernetes.sh NODE token MASTERIP来join,其他的诸如docker和kubelet/kubectl/kubeadm等的安装,container的事前下载都写进去了,版本全部目前统一为1.4.1的版本,脚本及其简单,无非将google的步骤放到一起而已,可以自行按自己需要进行修改。
创建Master
创建master在kubernetes1.4的版本只需要一条命令,kubeadm init, 但是其前提是能够联上网络,kubeadm会自动地按照需求去pull相应的image的版本,所以省去了翻来覆去的确认各个image等的版本,但是安装过程会慢一些,如果你查看linux的系统日志你就会发现/var/log/messages中只有在安装的时候在本地找不到正确版本的image的时候才回去pull,所以事前把所需要的内容都pull下来是一个很好的主意。
命令:
git clone https://github.com/liumiaocn/easypack
cd easypack/k8s
sh easypack_kubernetes.sh MASTER
>实际执行的时候不需要一定设定本地git,将上面github上面的脚本easypack_kubernetes.sh的内容copy下来在本地vi生成一个即可
安装耗时:10分钟(基本上都是在pull google_container的镜像)
输出参照:
[root@host31 ~]# git clone https://github.com/liumiaocn/easypack
Cloning into 'easypack'...
remote: Counting objects: 67, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 67 (delta 11), reused 0 (delta 0), pack-reused 15
Unpacking objects: 100% (67/67), done.
[root@host31 ~]# cd easypack/k8s
[root@host31 k8s]# sh easypack_kubernetes.sh MASTER
Wed Nov 9 05:05:53 EST 2016
##INSTALL LOG : /tmp/k8s_install.1456.log
##Step 1: Stop firewall ...
Wed Nov 9 05:05:53 EST 2016
##Step 2: set repository and install kubeadm etc...
install kubectl in Master...
#######Set docker proxy when needed. If ready, press any to continue...
注意:此处需要回车一下才能继续,因为需要给安装完docker还要设定docker的代理的提供一个手动处理的方式,不通过代理的直接回车即可
Wed Nov 9 05:07:04 EST 2016
##Step 3: pull google containers...
Now begin to pull images from liumiaocn
No.1 : kube-proxy-amd64:v1.4.1 pull begins ...
No.1 : kube-proxy-amd64:v1.4.1 pull ends ...
No.