前言：服务网格演变史
还记得17年的夏天，我第一次接触docker，立刻就被容器化的新颖理念以及它带来的种种优势所震撼了
容器化带给业界的冲击是巨大的，不到短短一年的时间里，容器化的部署和运维就已经彻底替代传统机器部署成为了主流，同时docker也为服务端的发展形态带来了非常多的可能性，使得“微服务”这一架构如雨后春笋般生长起来，迅速成熟
当服务的载体由虚拟机器变为容器后，部署和运维的粒度更小了，但从宏观的角度来看，一个完整的服务系统变得更加零碎和复杂了 —— 数量众多的微服务以及承载他们的容器交织成一张脉络复杂的巨网，如何对这样庞大的系统进行管理便成为一个难题
那一年，k8s还没有“爆红”，谈到容器管理，人们的第一反应仍然是docker官方团队著名的“三剑客”：
docker-machine提供底层的跨平台虚拟
docker-compose解决复杂服务的自动部署
docker-swarm实现大型集群的管理
一切看起来都很美妙，直到半路杀出google孕育的k8s，以其强大的功能和扁平易用的管理方式一统江湖，2018年我们几乎再也看不到三剑客的身影，k8s和lstio以及它们所带来的“服务网格”正在成为云原生时代新的基础设施，越来越多的大型系统开始在云上构建和部署
作为一个工程师，应当有意识的去了解自己服务究竟生长在什么样的一片土壤上，这也正是本次开坑学习k8s的原因
整体概览
什么是k8s?
Kubernetes是一个用于容器集群的自动化部署、扩容以及运维的开源平台。
k8s诞生的目的
k8s孕育的初衷是培育出一个组件及工具的生态，帮助大家减轻在公有云及私有云上运行应用的负担，换言之，使得大型分布式应用的构建和运维变得更加简单（当然，越简单的表面意味着越复杂的内部细节）。
整体架构图
下面逐步展开介绍各个组件
组件一览
Node: 硬件节点
Node是k8s中最小的计算硬件单元，它类似于传统集群中单台机器的概念，是对硬件物理资源的一层抽象，它可以是真实机房的物理机器，又或者是云平台上的ECS，甚至可以是边缘计算的一个终端。
无论如何，借助Node的抽象，我们可以把任何一台机器简单的看做是一组CPU和RAM资源的组合，从而达到解耦的效果
Cluster: 集群
对于大型系统，我们往往不会把关注点放在单个机器上，而是聚焦更大粒度的集群。
在k8s中，一般将集群看做一个整体，而不关心内部节点的状态，集群内部状态的调整将由k8s自动完成。
Persistent Volumes: 持久卷
考虑到集群内部的节点始终在发生调度和变动，所以所有节点内部的文件系统都是易失的，无法保证持久，为了解决这一问题，k8s引入了持久卷的概念，用于映射实际的物理储存节点（云盘或者是物理磁盘），它可以随时被挂载到任何的集群上去。
Container: 容器
容器是打包好的运行环境，这点无需再多赘述。值得一提的是k8s中的容器支持不仅仅包含了docker，还支持一些其他的容器标准
Pod
这是k8s区别于其他容器编排平台的一个显著特点：它不直接运行容器，而是运行一种称为Pod的高级结构，里面封装了一系列相关的容器，并共享相同的namespace和网络。
Pod也是k8s进行服务编排和缩扩容的基本单位，这意味着Pod里所有的容器都会被一并缩放(不管是否有必要)，因此定制Pod时应该使它的体积尽可能小一些。
另外还有一个和Pod相关的概念，就是副本集(Replica Sets)，它是指在扩容时产生的Pod的复制
我们可以把上面几个逻辑概念的关系用下图表示：
Deployment: 部署
deployment是用于管理pod的抽象层，它的定位类似于docker-compose。
k8s一个很巧妙的地方在于它把deployment层设计成“过程无关”的，你只需要声明你所期望的最终状态，k8s将会自动为你调度pod并保证它们满足你的预期。
Ingress: 入口
当我们将整个系统以及其精巧的内部结构搭建起来后，我们仍然需要一个通道，使得它能够真正地与外界沟通，这就是Ingress
HelloWorld
了解一门技术最快的方法就是用它写一个Hello World，由于真实的k8s需要部署在较大规模的集群上，普通的开发PC显然不能达到这个需求，所以使用官方提供的本地实验环境工具minikube来做尝试
(以下实践均运行在OSX 10.11环境下)
准备
首先需要安装minikube + kubectl，因为minikube需要docker作为底层支持，所以你还需要先提前安装好docker，docker的安装就不多赘述了，这里说下如何在国内环境安装另外两个重要的组件：
kubectl的安装：wget https://storage.googleapis.com/kubernetes- release/release/v1.5.1/bin/darwin/amd64/kubectl chmod +x kubectl mv kubectl /usr/local/bin/kubectlminikube的安装：首先需要安装
VirtualBox作为底层的driver，然后从命令行安装。这里用的是阿里云在国内的源，所以会比brew快很多curl -Lo minikube http://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.0.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
安装完毕后可以启动k8s环境了，命令行运行minikube start，可以看到它会自动更新和下载一些组件（这个过程可能会持续几分钟）
启动完毕后运行minikube ssh进入minikube的虚拟机内部，执行docker ps查看所有的组件容器是否启动成功
如果没有问题退出登录，在外部执行minikube dashboard即可在浏览器启动控制台，到这里k8s的实验环境就已经搭建完毕了
部署应用
k8s环境启动后，就可以开始部署应用和服务了。首先我们需要一个可用的应用镜像，这里用我自己打包好的一个简单的Http Hello World服务镜像来做示范（镜像地址：registry.cn-qingdao.aliyuncs.com/gold-faas/gold-rest-demo:1.0）
接下来第一步就是创建Deployment，它将负责创建和更新我们的应用实例，并且持续监控应用的状态。
使用kubectl来创建一个deployment:
kubectl run helloworld --image=registry.cn-qingdao.aliyuncs.com/gold-faas/gold-rest-demo:1.0 --port=8080执行后master节点将会选择一个合适的node来部署该应用（minikube环境下只有一个node），创建完成后可以使用kubectl get deployment来查看该应用：
此时控制台中也可以看到相应的部署：
访问应用
应用部署好后，暂时还只能在内部访问，我们可以进入pod内部来做一个测试：
可以看到服务已经在正常运行了，如果想要在外部的终端访问，可以简单的使用kubectl proxy来创建一个当前终端到k8s cluster的代理，然后来访问我们的pod（可以先用kubectl get pod来查看pod名）
代理启动后在新终端通过restful api的方式就可以通过代理访问到内部pod所提供的服务，restful的url模式如下：
/api/v1/namespace/{namespace}/pods/{name}/proxy/{path:*}效果：
（这是k8s对外暴露的resftul api的一部分，是通过代码和网络手段控制k8s的重要手段，后面会再详细展开讲）
创建Service
上面使用proxy来访问内部容器的方法更多适合在debug等场景下使用，当我们需要对外提供可用的真实服务时，需要更加可靠的手段，那就是Service，可以暂时把它理解为一个集合了负载均衡、服务发现等功能的外部服务入口（后面再详细展开）。
如图，一个Service可以映射多个Pod，为了把多个Pod在逻辑上组合起来，k8s又引入了Label的概念，简单的说就是每个Pod上都可以打一个Label（标签），具有相同Label的Pod就成为一个逻辑分组。Service就是通过Label Selector的方式来关联多个Pod的，如下图：
现在我们来创建一个Service并将它暴露到外部，通常可以有LoadBalancer和NodePort两种手段，不过minikube只支持后者，使用kubectl expose命令即可创建Service:
使用kubectl get service我们可以看到已经创建的服务，其中kubernetes是k8s默认已经创建好的。可以看到，新创建的service把对应pod的8080端口暴露到了外部的32344端口，接下来通过这个端口就可以访问到hello world服务了：
这里的ip是minikube的docker-daemon的ip，可以通过minikube docker-env来查看：
我们可以查看一下service和pod的详情，来看看Label是否按照我们预期的被创建：
label是key=value的形式被创建的，如果想要自定义一些label，使用kubectl label命令即可：
在pod和service非常多的时候，可以用作一种过滤的手段，使用-l参数即可进行筛选，就像sql的where语句一样：
最后，如果想要删除一个service，只需要运行kubectl delete service [服务名]即可，当然服务删除后pod仍然存在并且会持续运行，只是对外的入口消失了而已。
小结
到这里，k8s的基础概念已经介绍的差不多了，也了解了如何在k8s上部署应用和服务，get了大概的运作流程。不过目前能看到的只是k8s基础能力的一部分，更多的实践以及背后的工作原理，还请期待后文！
