1 kubernetes核心概念
1.1 Pod
Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。
Pod就像豌豆荚一样，其中包含着一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。
Pod就像一台物理服务器一样，其中包含一个或多个应用容器，这些容器中运行着用户应用程序。
举例说明Pod、Container、应用程序三者之间的关系：麻屋子，红帐子，里面住着白胖子。Pod就是麻屋子，Container就是红帐子，应用程序就是里面的白胖子。
1.2 Controller
在Kubernetes中，用于管理和运行Pod的对象
在Kubernetes中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态
举例说明Controller（控制器）作用：房间里的温度自动调节器
当你设置了温度，告诉了温度自动调节器你的期望状态（DesiredState）。房间的实际温度是当前状态（CurrentState）。通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。
一个控制器至少追踪一种类型的Kubernetes资源。这些对象有一个代表期望状态的spec字段。该资源的控制器负责确保其当前状态接近期望状态。不同的类型的控制器所实现的控制方式不一样，例如：
Deployment
- 部署无状态应用。
- 部署无状态应用：认为pod都一样，没有顺序要求，不用考虑在哪个node运行，随意进行扩展和伸缩。
- 管理Pod和 ReplicaSet
- 部署、滚动升级等。
- 典型的像web服务、分布式服务等
StatefulSet
- 部署有状态应用
- 有状态应用，每个pod都独立运行，保持pod启动顺序和唯一性；有唯一的网络标识符，持久存储；有序，比如mysql主从；主机名称固定。而且其扩容以及升级等操作也是按顺序进行的操作。
DaemonSet
- 部署守护进程
- DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。新加入的node也同样运行在一个pod里面。
job
- 一次性任务。
- Job负责批量处理短暂的一次性任务（shortlivedone-offtasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。
Cronjob
- 周期性定时任务。数据库备份。
1.3 Label
Label是附着到object上（例如Pod）的键值对。可以在创建object的时候指定，也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义，只是对用户才有意义。
一个Label是一个key=value的键值对，其中key与value由用户自己指定。
Label可以附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去，Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。
我们可以通过指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如：部署不同版本的应用到不同的环境中；或者监控和分析应用（日志记录、监控、告警）等。
Label相当于我们熟悉的“标签"，给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过LabelSelector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。
1.4 Label Selector
通过label selector，客户端/用户可以指定一个object集合，通过label selector对object的集合进行操作。
Labelselector有两种类型：
- equality-based（基于等式）：可以使用=、==、I=操作符，可以使用逗号分隔多个表达式
- set-based（基于集合）：可以使用in、notin、！操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个key的object而不管该key的value是何值，！表示没有该label的object
当我们给一组对象，比如有10个pod，打上了不同的标签之后，当我们要选择其中的部分，或者全部作为使用目标的时候，就可以使用label selector来实现这个操作，标签选择器中指定具体的过滤的条件，然后，就能在10个pod中过滤出满足我们要求的这些pod。
1.5 Service
将运行在一组Pods上的应用程序公开为网络服务的抽象方法。
由于Pod是非永久性资源对象，如果你使用Controller运行你的应用程序，你可以动态创建和销毁Pod，这样就会导致无法准确访问到所想要访问的Pod
例如：如果一组Pod（称为"后端"）为集群内的其他Pod（称为"前端"）提供功能，那么前端如何找出并跟踪要连接的IP地址，以便前端可以使用提供工作负载的后端部分？
是一组iptables或ipvs规划，通过把客户端的请求转发到服务端（Pod），如有多个Pod情况，亦可实现负载均衡的效果。
例如：一个图片处理后端，它运行了3个副本（Pod）。这些副本是可互换的一一前端不需要关心它们调用了哪个后端副本。然而组成这一组后端程序的Pod实际上可能会发生变化，前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。
1.6 Endpoints
为Service管理后端Pod，当后端Pod被创建或销毁时，endpoints列表会更新Pod对应的iP地址，以便Service访问请求能够确保被响应。
1.7 DNS
为kubernetes集群内资源对象的访问提供名称解析，这样就可以实现通过DNS名称而非IP地址来访问服务。
- 实现集群内Service名称解析
- 实现集群内Pod内Container中应用访问互联网提供域名解析
2 kubernetes核心概念之间关系
2.1 pod与controller
Controller通过API Server与Kubernetes集群通信，监控Pod的状态，并根据需要进行调整。这种设计使得Kubernetes能够提供高可用性和弹性伸缩的能力。
pod是通过Controller实现应用的运维，比如伸缩，滚动升级等待。pod和controller通过label标签建立关系。
2.2 pod与service
service是为了防止pod失联，提供的服务发现，类似于微服务的注册中心。定义一组pod的访问策略。可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求负载分发到后端的各个容器应用上。
service通过selector来管控对应的pod。根据label和selector建立关联，通过service实现pod的负载均衡。
3 基于kubernetes集群容器化应用的微服务
3.1 服务部署方式介绍
单体服务架构
- 所有服务进程运行在同一台主机内。
分布式服务架构
- 服务进程分布于不同的主机，其中一台主机出现故障，不影响其它主机上的服务运行。
微服务架构
- 使用容器化技术把分布式服务架构运行起来，并实现对不同的服务进程的高可用及快速发布等。
3.2 服务组件之间的关系
service -> container -> service -> container
pod出现故障，controller重新把pod拉起，pod 的 ip地址发生变化，service通过label标签寻找到相对应的pod，将pod信息添加到endpoint上，对pod发起请求时仍旧可以连接到。
