author：魏斌
初识Docker，那时他还是一家叫DotCloud的公司，和ClodBee，Openshift，CloudFundary等一样提供PAAS服务，由于PAAS服务厂商之间竞争激烈，DotCloud举步维艰，失望之余，2013年DotCloud开放了他的核心项目，一个打包linux下的打包程序，应用可以非常容易的在服务器之间迁移。
无心插柳，柳成荫，Docker迅速受到Google，WMwave，微软，Ebay，Box和Facebook的青睐，策马征战天下，在很短的时候内迅速获得了大量技术人员关注，DotCloud更是更名为Docker inc来彰显支持Docker的决心，容器的技术当然不仅仅只有Docker一种，但是，Docker已经成为容器事实上的标准。可以说，终于出现了一种技术，真正意义上实现了“write
once，run anywhere”，这也是让业界激情澎湃的根本原因。
Kubernetes源自Google，在Docker还没有自己的容器编排组件Swarm的时候，Google向开源界贡献了他们的容器编排系统
Kubernetes容器集群管理系统，它构建于Docker容器技术之上，为容器化的应用提供了资源调度、部署运行、服务发现、运行时扩容缩容等整一套解决方案，利用Kubernetes提供的功能，我们可以非常方便的管理不同主机上部署在容器的应用.
Kubernets简称K8s或Kube，用户可以通过预定义的方式管理集群，什么是预定义的方式？你可以把它理解为无人值守的自动化管理。例如用户可指定他想运行三个Redis容器的实例。K8s拥有容器自我修复机制，如自动重启，重新计划和容器备份帮助达到你想要的状态。
K8s支持Docker和Rocket两种容器，Google白皮书宣称，未来将对容器层进行抽象，帮助K8s支持更多格式的镜像格式和运行组件.
以一文介绍Kube构建分布式应用的过程
K8s的基本元素
Pod是Kubernetes最基本的部署单元，可以包含container，逻辑上表示应用的逻辑组合。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个pod
Service定义了一个Pod的逻辑集合和访问这个集合的路由策略，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以固定的方式去访问pod提供的服务。service的引入旨在做pod的动态映射对访问端屏蔽变化，访问端只需要知道service的地址，由service来提供代理。
Replication Controller简称RC是Pod的副本控制器，用于解决pod的扩容缩容问题，管理Pod的生命周期。通常，分布式应用为了实现高性能或高可用性的考虑，需要多个副本，并且根据负载情况动态伸缩。通过RC，我们可以指定一个应用需要几份复制，Kubernetes将为每份复本创建一个pod，并且保证实际运行pod数量总是与定义的复本数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。
LabelService和RC都是建立在Pod之上的抽象，最终要在pod上产生效果，那么它们怎么跟pod联系起来呢？这就要引入label的概念：label就是为pod加上可用于搜索或关联的一组key/value标签，而service和replicationController正是通过label来与pod关联的。比如，有三个pod都有label为"app=backend"，创建service和replicationController时可以指定同样的label:"app=backend"，再通过label selector机制，就将它们与这三个pod关联起来了。例如，当有其他frontend pod访问该service时，自动会转发到其中的一个backend pod。
VOLUMES
Vloume是可以是一个是宿主机器的文件夹地址或者另外一个容器，容器会被销毁或者重启时，容器内的应用产生的数据或者文件将被丢弃，多数情况下，我们需要保留一些信息，如mysql生成的数据库文件，或者是应用运行时使用的配置文件，又或是应用产生的日志文件，容器被重启后，这些文件都将被容器内的应用继续使用，以保证我们应用的延续性，这时，我们就需要使用到
Kurbernetes架构
和通常的集群环境一样，kurbernetes集群也需要Master和Slave(这里我们叫Work
Node)， 管理集群中所有机器的节点叫做Master Node，通过Master主机来管理WorkNode，Work Node上跑的就是我们的Pod。
Master Node是集群的中央控制器，为集群提供统一的视图。为了达到集群的高可用性，通常我们会在集群中创建多个Master Node,以防止单点故障时，重新选举Master
Work Node是集群中的工兵，用来执行Master Node委派的任务，在kuberneter架构中，一个Work Node可以装载多个Pods
Kuberlet
Kubelet是k8s和Docker daemon通信的关键组件。在每一个主机上都会起一个kubelet的进程来创建，销毁Pods以及同步状态
Kuberctl是管理kube集群的命令行工具，格式如下
kubectl [command] [type] [name] [flags]
• [command]对资源的操作指令 如create，describe，delete或者scale
• [type]指定kuber的资源类型 如pod，service，replicationController或者node .
• [name]设置资源运行时的名称
运行你的第一个容器
我们可以使用kubectl命令创建或者运行容器，kubernetes提供了一种最简单的方式，通过指定镜像名称来创建一个容器
kubectl run redis-master --image=docker.io/redis
通过get pods查看生成的Pod信息
kubectl.sh get po
NAME READY STATUS RESTARTS AGE
reids-1-3061617885-kkmt6 1/1 Running 0 1m
另外，可以通过配置文件创建pod
kubectl create -f redis-pod.yaml
构建可伸缩的应用
Pod在RC的管理下具有自动伸缩的特性
kubectl.sh scale
--replicas=3 rc redis replicationcontroller “redis” scaled
通过replicas参数可以设置RC管理的Pod实例，在上面的例子中，rc会在运行的集群环境中始终保持3个独立的实例
多容器应用
典型的应用一般由前端和后端组成，简单的架构一般是前端有一个应用服务器，比如PHP，后端有一个数据库提供数据持久化，比如redis。
应用步骤如下：
1启动“backend”的RC：后端服务的RC必须含有Redis Pod的spec
2启动”backend“的service : Redis Service使用selector来定位上一步启动的Pod
3启动“Fronetend”RC：Php RC必须包含Php的Pod
spec,而Pod必须包含应用的预部署，通常我们会扩展Php的镜像，并拷贝程序包到nginx的目录，然后再创建一个新的镜像，容器中的应用可以发现并连接数据库。
Namespace，Resources Quotas and Limits
默认情况下，Kube集群中的用户资源都在默认的NameSpace - “default”下,而Kube所创建对象的Namespace为“kube-system”
./kubernetes/cluster/kubectl.sh get namespace
NAME LABELS STATUSAGE
default Active 1m
kube-system Active 1m
用户创建的资源可以被划分为多个namespace，namespace之间相互隔离，这样就可以为资源创建逻辑分组。
1.独立的作用域以避免命名冲突
2.确保对信任用户适合的授权
3.约束指定资源的消耗
使用配置文件创建新的namespace
apiVersion: v1
kind: Namespace
metadata:
name: development
labels:
name: development
在默认namespace下创建RC
kubectl.sh create -f redis-rc.yml
replicationcontroller “redis” created
在指定的namespace下创建一个RC
kubectl.sh --namespace=development create -f redis-rc.yml
replicationcontroller “redis” created
通过配置文件指定资源配额，具体如下
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: “20”
memory: 1Gi
pods: “10”
replicationcontrollers: “20”
resourcequotas: “1”
services: “5”
创建POD时指定资源访问配额
apiVersion: v1
kind: Pod
metadata:
name: redis-pod
spec:
containers:
- name: redis
image: docker.io/redis
ports:
- containerPort: 8091
resources:
limits:
cpu: “1”
memory: 512Mi
Namespace，Resource Quota和Limits可以是Kube集群在多个分组之间共享资源并且能为每个分组提供不同程度的QOS（服务质量）
Kube Dashbord
Dashbord为我们提供了一个便捷的控制台，可以在一定程度上摆脱枯燥的命令行操作，可以用来管理Node，部署应用，性能监控等等。
author：魏斌 未授权请勿转载.......
通过简单的介绍，相信你已经对kube的威力有了直观的了解。在现代微服务架构日渐流行的今天，kube为我们构建大型系统提供了基础的支撑,即使你不是具备大型架构能力的工程师，只要能够精通kubenetes的使用，你也可以构建起一个高可用，动态伸缩，固若金汤的分布式系统。下面看看Kube为我们解决了哪些问题呢？
1.服务发现 在大型分布式系统，我们通常会使用ESB，dubbo，ZeroICE等RPC框架， 或者直接用硬件负载均衡器，来完成服务发现和路由中转的功能，而kube的基础组件直接支持了此功能，无需我们做额外的工作。
2.运维监控 分布式系统中，偶尔会发生服务不可用的情况，俗称脑裂，这种问题隐藏极深，没有邮件的资源监控机制，一般排查问题会话费大量的时间，而kube做到了自动监控，关闭出问题的服务，自动重启。
3.动态扩容 扩容分为纵向扩容和横向扩容，kube通过RC实现了通过配置自动的创建，销毁，增加或缩减实例，通过 为横向扩容提供了有力的支持；在纵向扩容方面，kube的Resource Quoter也能做到精准调配硬件资源的使用。
4.系统的高可用性 使用Kube的namespace和label，我们可以实现多集群部署，做到资源隔离，从而方便的实现多维度管理，灰度发布，冷热切换，双线备份等等以往需要硬件才能支持的工作。
5.应用部署kube提供了官方的dashbord，可以用来部署应用，也可以用来监控容器运行的健康度，当然，喜欢自己开发自动化工具的人也可以通过kube的api，开发出更加高级的工具。
