最近在学习k8s，这是笔记
应用类资源主要是围绕Service和Pod两个资源类型展开的。
一般来说，Service指的是无状态服务，通常由对应的多个程序副本(Pod实例)提供，在特殊情况下也可以是有状态单实例服务，比如MySQL这种数据库存储服务。Service既可以是TCP服务，也可以是UDP服务，还可以是SCTP服务，对具体的应用层协议的内容并没有任何限制。SCTP(Stream Control Transmission Protocol，流控制传输协议)是一个基于IP的可靠的面向控制信令的传输层协议，在电信领域被广泛应用，可以为电信级信令提供高效、可靠的传输服务，在5G核心网中也被应用。
与我们常规理解的服务不同，Kubernetes中的Service具有全局唯一的虚拟ClusterIP地址，Service一旦被创建，Kubernetes就会自动为它分配一个可用的ClusterIP地址，而且在Service的整个生命周期内，它的ClusterIP都不会改变，客户端可以通过【虚拟IP地址+服务的端口】的形式直接访问服务，在通过部署Kubernetes集群的DNS服务，就可以实现Service Name（域名）到ClusterIP地址的DNS映射功能，我们只要使用服务的名称（DNS名称）即可顺利完成到目标服务的访问请求。这样，【服务发现】这个传统架构中的棘手问题首次得到完美解决。同时，凭借ClusterIP地址的独特设计，Kubernetes进一步实现了Service透明负载均衡和故障自动转移和恢复的高级特性。
通过分析、识别并建模系统中的所有服务为微服务 —— Kubernetes Service, 我们的系统最终由多个提供不同业务能力而又彼此独立的微服务单元组成，服务之间通过 TCP/IP通信，形成了强大又灵活的弹性网络，拥有强大的分布式、弹性扩展和容错能力，程序框架也变得简单和直观许多。
接下来说说与Service密切相关的核心资源对象 —— Pod。
Pod是Kubernetes中最重要的基础概念之一，每个Pod都有一个特殊的被称为【根容器】的Pause容器，Pause容器对应的镜像属于Kubernetes的一部分，除了Pause容器，每个Pod都还有一个或者多个紧密相关的用户业务容器。
为什么Kubernetes会设计出一个全新的Pod概念，并且Pod会有这样的特殊组成结构？原因如下：
Pod作为基本的调度、复制等管理工作的最小单位，能让多个应用进程一起有效的调度和伸缩Pod中的多个业务容器共享Pause容器的IP，并且共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好的解决了他们之间的文件共享问题。Kubernetes 为每个Pod都分配了一个唯一的IP,称之为【Pod IP】，一个Pod中的多个容器共享Pod IP地址。Kubernetes要求底层网络支持集群中任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术实施，例如Flannel、Open vSwitch等，因此我们需要记住一点：在Kubernetes中，一个Pod中的容器与其他主机上的Pod容器能够直接通信。
Pod其实有两种类型：普通Pod和静态Pod(Static Pod)。静态Pod比较特殊，并没有被存放在Kubernetes的etcd中，而是被存放在某个具体的Node上的一个具体文件中，并且只能在此Node上启动、运行。而普通Pod一旦被创建，就会被存放在etcd中，随后进程实例化成一组相关的Docker容器并启动。在默认情况下，当Pod中的某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个Pod（重启Pod中的所有容器），如果Pod所在的Node宕机，就会将这个Node上所有的Pod都重新调度到其他节点。
下面是我们在之前的Hello, World实例里用到的myweb这个Pod的资源定义文件：
apiVersion: v1
kind: Pod
metadata:
name: myweb
labels:
name: myweb
spec:
containers:
- name: myweb
image: kubeguide/tomcat-app:v1
ports:
- containerPort: 8080在以上定义中，kind属性的值为Pod，表明这是一个Pod类型的资源对象; metadata里的name属性为Pod的名称，在metadata里还能定义资源对象的标签，这里生命myweb拥有一个name=myweb标签。在Pod中所包含的容器组的定义则在spec部分中声明，这里定义里一个名为myweb且对应的镜像为kubeguide/tomcat-app:v1的容器，并在8080端口（containerPort）启动容器进程。Pod的IP地址加上这里的容器端口组成里一个新的概念 —— Endpoint，代表此Pod的一个服务进程的对外通信地址。一个Pod也存在具有多个Endpoint的情况，比如当我们把Tomcat定义为一个Pod时，可以对外暴露管理端口和服务端口这两个Endpoint。
我们所熟悉的Docker Volume在Kubernetes也有对应的概念 —— Pod Volume, Pod Volume被定义在Pod中，然后被Pod的各个容器挂载（Mount）到自己的文件系统中。Volume简单来说就是被挂载到Pod容器中的文件目录。
这里顺便提一下Kubernetes中的Event概念，Event是一个事件记录，记录里事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此次事件的原因等众多信息。Event记录通常会被关联到某个具体的资源对象上，是排查故障的重要参考信息。之前我们看到在Node的描述信息中包括Event，而在Pod的描述信息中同样包括Event，当我们发现某个Pod迟迟无法创建时，可以通过kubectl describe pod xxxx命令查看它的描述信息，以定位问题的成因。
在继续说明Service和Pod的关系之前，我们需要先理解Kubernetes中的一个重要机制 —— 标签匹配机制。