上篇文章主要带大家了解了集群类资源，本文将带大家学习应用类资源的service与pod。应用类相关的资源对象主要围绕service（服务）与pod这两个核心对象展开的。Service指的是无状态服务，通常由多个程序副本提供服务，在特殊情况下也可以是有状态的单实例服务，比如mysql这种数据存储类服务。与我们常规理解的服务不同，k8s里的service具有一个全局唯一的虚拟ClusterIP地址，service一旦被创建，k8s就会自动为它分配一个可用的ClusterIP地址，而且在service的整个生命周期中，它的ClusterIP地址都不会改变，客户端可以通过这个虚拟ip地址+服务的端口直接访问该服务，在通过部署k8s集群的DNS服务，就可以实现service name（域名）到ClusterIP地址的DNS映射功能，我们只要使用服务的名称（DNS名称）即可完成到目标服务的访问请求。ClusterIP地址的独特设计，k8s进一步实现了service的透明负载均衡和故障自动修复的高级特性。识别并建模系统中的所有服务为微服务---k8s service，我们的系统最终由多个提供不同业务能力而又彼此独立的微服务单元组成，服务之间通过TCP/IP进行通信，从而形成强大又灵活的弹性网络，拥有强大的分布式能力、弹性扩展能力、容错能力，程序架构也变得简单和直观许多，如下图所示k8s提供的微服务网格架构：Pod是k8s中最重要的基本概念之一，每个pod都有一个特殊的被称为“根容器”的pause容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod都还包含一个或多个用户业务容器，pod结构如下图：为什么k8s会设计出一个全新的pod概念并且pod有这样特殊的组成结构？- 为多进程之间的协作提供一个抽象模型，使用pod作为基本的调度、复制等管理工作的最小单位，让多个应用进程能一起有效地调度和伸缩。
- Pod里的多个业务容器共享pause容器的ip，共享pause容器挂接的volume，既简化了业务容器之间的通信问题，又解决了容器之间的文件共享问题。
K8s为每个pod都分配了唯一的ip地址，称之为pod ip，一个pod里的多个容器共享pod ip地址。K8s要求底层网络支持集群内任意两个pod之间的TCP/IP直接通信，通常采用虚拟二层网路技术实现，例如：flannel、open vswitch等。在k8s里，一个pod里的容器与另外主机上的pod容器能够直接通信。静态pod：没有存放在k8s的etcd中，被存放在某个具体node上的一个具体文件中，并且只能在此node上启动、运行。普通pod：pod一旦被创建就会被放入etcd中存储，随后被k8s master调度到某个具体的node上并绑定（binding），该pod被对应node上的kubelet进程实例化成一组相关的docker容器并启动。 当pod中的某个容器停止时，k8s会自动检测到这个问题并重启pod（重启pod里的所有容器）。 当pod所在的node宕机，就会将这个node上所有的pod都重新调度到其他节点上。apiVersion:v1
kind:Pod
metadata:
name:myweb
labels:
name: myweb
spec:
containers:
- name:hello
image:kubeguide/tomcat-app:v1
ports:
- containerPort:8080
kind：资源对象的类型，此处表示为pod类型的资源对象spec.containers：声明pod里包含的容器组定义 Endpoint由pod的ip和容器的端口号组成，代表此pod里的一个服务进程的对外通信地址。一个pod里可以有多个endpoint。
Pod volume与docker 的volume对应，它被定义在pod上，被各个容器挂载到自己的文件系统中。Pod volume即挂在pod里的文件目录。
Event是一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致事件的原因等众多信息。Event通常会被关联到某个具体的资源对象上，是排查故障的重要参考信息。Node、pod的描述信息里面都包含event记录，可以通过kubectl describe node/pod xxxx 查看某个node或pod的描述信息。
