书籍来源：《Kubernetes进阶实战（第2版）》
一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！
附上汇总贴：Kubernetes进阶自学系列 | 汇总_COCOgsta的博客-CSDN博客
1.3.1 Pod与Service
Pod本质上是共享Network、IPC和UTS名称空间以及存储资源的容器集合，如图1-9所示。我们可以把每个Pod对象想象成一个逻辑主机，而运行于同一个Pod对象中多个进程则类似于物理机或虚拟机上独立运行的进程，不同的是，Pod中各进程运行于彼此隔离的容器中，并与各容器间共享网络和存储两种关键资源。
同一Pod内部的各容器具有“超亲密”关系，它们共享网络协议栈、网络设备、路由、IP地址和端口等网络资源，可以基于本地回环接口lo互相通信。每个Pod上还可附加一组“存储卷”（volume）资源，它们同样可由内部所有容器使用而实现数据共享。
同时，这些以Pod形式运行于Kubernetes之上的应用通常以服务类程序居多，如图1-10所示。Kubernetes集群的网络模型要求其各Pod对象的IP地址位于同一网络平面内（同一IP网段），各Pod间可使用真实IP地址直接进行通信而无须NAT功能介入。
Pod对象拥有生命周期，它会在自身故障或所在的工作节点故障时被替换为一个新的实例，其IP地址通常也会随之改变。为此，Kubernetes设计了有着稳定可靠IP地址的Service资源，作为一组提供了相同服务的Pod对象的访问入口。
Service是由基于匹配规则在集群中挑选出的一组Pod对象的集合、访问这组Pod集合的固定IP地址，以及对请求进行调度的方法等功能所构成的一种API资源类型，是Pod资源的代理和负载均衡器。Service匹配Pod对象的规则可用“标签选择器”进行体现，并根据标签来过滤符合条件的资源对象。
kube-proxy组件负责管理各Pod与Service之间的网络连接，它是一个基于出站流量的负载均衡器组件。针对每个Service，kube-proxy都会在当前节点上转换并添加相应iptables DNAT规则或ipvs规则，从而将目标地址为某Service对象的ClusterIP的流量调度至该Service根据标签选择器匹配出的Pod对象之上。
Kubernetes使用定制的DNS服务为这类需求提供了自动的服务注册和服务发现功能。CoreDNS附件会为集群中的每个Service对象（包括DNS服务自身）生成唯一的DNS名称标识，以及相应的DNS资源记录，服务的DNS名称遵循标准的svc.namespace.svc.cluster-domain格式。
Service资源的名称和ClusterIP在其整个生命周期内都不会发生变动。kubelet会在创建Pod容器时，自动在/etc/resolv.conf文件中配置Pod容器使用集群上CoreDNS服务的ClusterIP作为DNS服务器，因而各Pod可针对任何Service的名称直接请求相应的服务。
1.3.2 Pod控制器
控制器持续监视对API Server上的API对象的添加、更新和删除等更改操作，并在发生此类事件时执行目标对象相应的业务逻辑，从而将客户端的管理指令转为对象管理所需要的真正的操作过程。图1-12中的Deployment就是这类控制器的代表实现，是目前最常用的用于管理无状态应用的Pod控制器。
Deployment控制器的定义通常由期望的副本数量、Pod模板和标签选择器组成，它会根据标签选择器对Pod对象的标签进行匹配检查，所有满足选择条件的Pod对象都将受控于当前控制器并计入其副本总数，以确保此数目能精确反映期望的副本数。
在接收到的请求流量负载显著低于或接近已有Pod副本的整体承载能力时，用户需要手动修改Deployment控制器中的期望副本数量以实现应用规模的扩容或缩容。用户还可以使用Horizontal Pod Autoscaler根据Pod对象的CPU等资源占用率计算出合适的Pod副本数量，并自动修改，如图1-13所示。
另外，StatefulSet控制器专用于管理有状态应用的Pod实例，其他常用的Pod控制器还有ReplicaSet、DaemonSet、Job和CronJob等，分别用于不同控制模型的工作负载。
1.3.3 Kubernetes网络基础
Kubernetes的网络中存在4种主要类型的通信：同一Pod内的容器间通信、各Pod彼此间通信、Pod与Service间的通信以及集群外部的流量与Service间的通信。Kubernetes对Pod和Service资源对象分别使用了专用网络，Service的网络则由Kubernetes集群自行管理。
Pod网络及其IP由Kubernetes的网络插件负责配置和管理。对比来说，Service的地址却是一个虚拟IP地址，由kube-proxy配置在每个工作节点上的iptables或ipvs规则中以进行流量分发。
Service IP也称为Cluster IP，专用于集群内通信，一般使用不同于Pod网络的专用地址段。集群内的Pod对象可直接用Cluster IP作为目标服务的地址，就像Pod对象直接提供了某种服务。
Kubernetes集群上会存在3个分别用于节点、Pod和Service的不同网络，3种网络在工作节点之上实现交汇，由节点内核中的路由组件以及iptables/netfilter和ipvs等完成网络间的报文转发，例如Pod与Service，Node与Service之间等的流量。
- 节点网络：各主机自身所属的网络，相关IP地址配置在节点的网络接口，用于各主机之间的通信，例如Master与各Node间的通信。此地址不能由Kubernetes管理，需要管理员在集群构建之前就自行确定其地址配置及管理方式。
- Pod网络：Pod对象所属的网络，用于各Pod间的通信。Pod网络是一种虚拟网络，常见的实现机制有Overlay和Underlay两种。
- Service网络：一个虚拟网络，通过Node上的kube-proxy配置为节点的iptables或ipvs规则，进而将发往此地址的所有流量调度至Service后端的各Pod对象之上；Service网络在Kubernetes集群创建时予以指定，而各Service的地址则在用户创建Service时予以动态配置。
Kubernetes集群上的服务大致可分为两种：API Server和服务类应用，它们的客户端要么来自集群内的其他Pod，要么来自集群外部的用户或应用程序。前一种通信通常发生在Pod网络和Service网络之上的东西向流量；而后一种通信是访问运行于Pod中的服务类应用的南北向流量。
访问API Server时，一般借助命令行工具kubectl或图形UI实现，也可通过编程接口实现，包括RESTful API。访问Pod中的应用时，具体访问方式取决于Pod中的应用程序，例如，对于运行Nginx容器的Pod来说，最常用的工具自然是HTTP协议客户端或客户端库，如图1-15所示。
管理员使用Kubernetes集群的常见操作包括通过控制器创建Pod，在Pod的基础上创建Service供第二类客户端访问，更新Pod中的应用版本（更新和回滚）以及对应用规模进行扩容或缩容等，另外还有集群附件管理、存储卷管理、网络及网络策略管理、资源管理和安全管理等。
1.3.4 部署并访问应用
Docker容器技术使得部署应用程序从传统的安装、配置、启动应用程序的方式转为在容器引擎上基于镜像创建和运行容器，而Kubernetes又让创建和运行容器的操作不必再关注其位置，并赋予了它一定程度上动态扩缩容及自愈的能力。
用到某应用程序时，用户向API Server请求创建一个Pod控制器对象，由控制器根据配置的Pod模板向API Server请求创建出一定数量的Pod实例，每个实例由Master之上的调度器指派给选定的工作节点，并由目标工作节点上的kubelet调用本地容器运行时创建并运行容器化应用。
集群外部客户端需要等边界路由器先将访问流量引入集群内部后，才能进行内部的服务请求和响应，NodePort或LoadBalancer类型的Service以及Ingress资源都是常见的解决方案。
kubectl是最常用的集群管理工具之一，它是API Server的客户端程序，通过子命令实现集群及相关资源对象的管理操作，并支持直接命令式、命令式配置清单及声明式配置清单三种操作方式。Dashboard则提供了基于Web界面的图形客户端，能在一定程度上替代kubectl的大多数操作。