一、Pod
在Kubernetes集群中，Pod是创建、部署和调度的基本单位。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个应用的容器。在同一个Pod内部，多个容器共享存储、网络IP，以及管理容器如何运行的策略选项。Docker是Kubernetes中最常用的容器运行时。
在Kubrenetes集群中，Pod有两种使用方式，如下所示：
一个Pod中运行一个容器
这种模式是最常见的用法，可以把Pod想象成是单个容器的封装，Kubernetes直接管理的是Pod，而不是Pod内部的容器。
一个Pod中同时运行多个容器
一个Pod中也可以同时运行几个容器，这些容器之间需要紧密协作，并共享资源。这些在同一个Pod中的容器可以互相协作，逻辑上代表一个Service对象。每个Pod都是应用的一个实例，如果我们想要运行多个实例，就应该运行多个Pod。
同一个Pod中的容器，会自动的分配到同一个Node上。每个Pod都会被分配一个唯一的IP地址，该Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如，使用宿主机的端口映射）。
我们可以为一个Pod指定多个共享的Volume，它内部的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。
我们可以使用Kubernetes中抽象的Controller来创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。当Pod被创建后，都会被Kuberentes调度到集群的Node上，直到Pod的进程终止而被移除掉。
Pod是在K8s集群中运行部署应用或服务的最小单元，支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
比如：运行一个操作系统发行版的软件仓库：使用一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；
这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。
Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。
目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet。
pod = pause容器 + 业务容器， 业务容器共享pause容器的网络栈和volume挂载卷。
上述例子中，pause容器，+两个业务容器，业务容器共享pause容器的网络栈和volume挂载卷。
二、Node
Node是Kubernetes集群的工作节点，它可以是物理机，也可以是虚拟机。
我们创建的Pod，都运行在Kubernetes集群中的每个Node节点上。而且，在每个Node上还会存在一个运行容器的daemon进程，比如Docker daemon进程，它负责管理Docker容器的运行。
Node在Kubernetes集群中也是一种资源，内部会创建该资源，定义Node示例如下所示：
三、namespace
在一个Kubernetes集群中，可以使用Namespace创建多个“虚拟集群”，这些Namespace之间可以完全隔离，也可以通过某种方式，使一个Namespace中的Service可以访问到其他Namespace中的Service。
查看当前Kubernetes集群中的Namespace列表，执行如下命令：kubectl get namespaces
Namespace是对一组资源和对象的抽象集合，如可以用来将系统内部的对象划分为不同的项目组或用户组。
- pods, services, replication controllers和deployments等属于某一个namespace（默认是default）
- node, persistentVolumes等则不属于任何namespace
默认情况下，会有两个系统自动创建好的Namespace：
- default：Kubernetes集群中没有Namespace的对象都会放到该默认Namespace中
- kube-system：Kubernetes集群自动创建的Namespace
创建一个名称为myns的Namespace，配置内容如下所示：
四、service
Service是应用服务的抽象，通过labels为应用提供负载均衡和服务发现，匹配labels的Pod IP和端口列表组成endpoints，由kube-proxy负责将服务IP负载均衡到这些endpoints上。
每个Service都会自动分配一个cluster IP（仅在集群内部可访问的虚拟地址）和DNS名，其他容器可以通过该地址或DNS来访问服务，而不需要了解后端容器的运行。
Service从逻辑上定义了一个Pod的集合以及如何访问这些Pod的策略，有时也被称作是微服务，它与Pod、ReplicaSet等Kubernetes对象之间的关系，描述如下图所示：
上图中，Client请求Service，Service通过Label Selector，将请求转发到对应的一组Pod上。
同时，ReplicaSet会基于Label Selector来监控Service对应的Pod的数量是否满足用户设置的预期个数，最终保证Pod的数量和replica的值一致。
在Kubernetes集群中，每个Node都会运行一个kube-proxy，它主要负责为Service实现一种虚拟IP的代理，这种代理有两种模式：
- userspace模式
这种模式是在Kubernetes v1.0版本加入的，工作在4层（传输层：TCPUDP over IP），称为userspace模式，如下图所示：
- iptables模式
这种模式是在Kubernetes v1.1版本新增的，它工作在七层（应用层：HTTP），称为iptables，如下图所示：
Service定义了4种服务类型，以满足使用不同的方式去访问一个Service，这4种类型包括：ClusterIP、NodePort、LoadBalancer、ExternalName。
- ClusterIP是默认使用的类型，它表示在使用Kubernetes集群内部的IP地址，使用这种方式我们只能在该集群中访问Service。
- NodePort类型，会在Node节点上暴露一个静态的IP地址和端口，使得外部通过NodeIP:NodePort的方式就能访问到该Service。
- LoadBalancer类型，通过使用Cloud提供商提供的负载均衡IP地址，将Service暴露出去。
- ExternalName类型，会使用一个外部的域名来将Service暴露出去（Kubernetes v1.7及以上版本的kube-dns支持该种类型）。
我们可以定义一个Service，对应的配置内容，如下所示：
以上定义的该服务是一个多端口服务，同时为该服务设置了一个负载均衡的IP（78.11.24.19），所有访问该服务的应用，通过该负载均衡IP地址都可以访问到该Service对应的Pod集合中的容器服务（应用服务）。
五、Label
Label是识别Kubernetes对象的标签，以key/value的方式附加到对象上（key最长不能超过63字节，value可以为空，也可以是不超过253字节的字符串）。
Label不提供唯一性，并且实际上经常是很多对象（如Pods）都使用相同的label来标志具体的应用。
Label定义好后其他对象可以使用Label Selector来选择一组相同label的对象（比如ReplicaSet和Service用label来选择一组Pod）。
Label Selector支持以下几种方式：
等式，如 app=nginx 和 env!=production
集合，如 env in (production, qa)
多个label（它们之间是AND关系），如 app=nginx,env=test
六、Annotations
Annotations是key/value形式附加于对象的注解。不同于Labels用于标志和选择对象，Annotations则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。
比如deployment使用annotations来记录rolling update的状态。
Node是Kubernetes集群的工作节点，它可以是物理机，也可以是虚拟机。我们创建的Pod，都运行在Kubernetes集群中的每个Node节点上。而且，在每个Node上还会存在一个运行容器的daemon进程，比如Docker daemon进程，它负责管理Docker容器的运行。
Node在Kubernetes集群中也是一种资源，内部会创建该资源，定义Node示例如下所示：
01 |
{ |
02 |
"kind": "Node", |
03 |
"apiVersion": "v1", |
04 |
"metadata": { |
05 |
"name": "10.240.79.157", |
06 |
"labels": { |
07 |
"name": "my-first-k8s-node" |
08 |
} |
09 |
} |
10 |
} |