Pod是最小最简单的Kubernetes对象Pod、Service、Volume和Namespace是Kubernetes集群中的四个基本对象，可以代表系统中部署的应用程序、工作负载、网络和磁盘资源。一起定义集群的状态。Kubernetes中的许多其他资源实际上只是结合了这些基本对象。Pod->集群中的基本单元Service->解决Pod中服务如何访问的问题Volume->存储卷集群中的Namespace->Namespace为集群提供虚拟隔离Kubernetes有很多技术概念，对应API对象有很多，其中最重要也是最基础的就是Pod对象。Pod是Kubernetes集群中运行和部署应用或服务的最小单元，可以支持多个容器。Pod的设计理念是支持多个容器在一个Pod内共享网络地址和文件系统，通过进程间通信和文件共享，以简单高效的方式完成服务。apiversion：v1kind：podmetadata：name：busybox标签：app：busyboxspec：容器：restartpolicy：restartpolicy：werfyd-name：busyboximage：busybox命令：-sleep-sleep-“3600”image-pullpolicy：ifnotpresentpodpodpodpodpodpodpodpodpodpod结构在同一个Pod中，有几个概念需要特别注意。第一个是容器。实际上，Pod中可以同时运行一个或多个容器。这些容器可以共享网络、存储和CPU/内存。和其他资源。首先，我们需要知道的是，每个Pod都有一个特殊的Pause容器，称为“根容器”。Pause容器对应的镜像是Kubernetes平台的一部分，Pause容器使得工作在对应Pod中的容器能够共享网络和共享存储。Pod共享资源为什么Kubernetes会设计一个结构如此特殊的全新Pod概念？主要原因是Pause容器作为Pod的根容器，它的状态代表了整个容器组的状态；其次，Pod中的多个业务容器共享Pause容器的IP地址和Pause容器附带的Volume资源。共享存储资源可以为一个Pod指定多个共享的Volume资源。Pod中的所有容器都可以访问共享卷资源。Volume也可以用来持久化Pod中的存储资源，防止容器重启后文件丢失。共享网络资源每个Pod都分配有一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内的容器可以使用本地主机相互通信。Pod中的容器与外界通信时，必须分配共享的网络资源，比如使用宿主机的端口映射。veth设备的特点一个设备从协议栈接收到数据发送请求后，会将数据发送给另一个设备。Veth与其他网络设备一样。一端连接到内核协议栈。veth设备成对出现，另一端的两个设备相互连接#物理网卡eth0的IP为192.168.1.11#veth0和veth1的IP分别为192.168.2.11和192.168.2.10+---------------------------------------------------------------+|||+--------------------------------------------------+||||网络协议栈||||+------------------------------------------------+||↑↑↑↑↑||......................................................|。..................|................||↓↓↓↓↓|||+---------+++---------++---------+|||eth0||veth0||veth1|||-++---------++---------+||192.168.1.11↑↑↑↑|||||------------------------------------------+PhysicalNetworkPod的网络通信集群网络方案：Kubernetes+FlannelKubernetes的网络模型假设所有的Pod都在一个直连的平面网络空间中，这是GCE（GoogleComputeEngine）中现成的网络模型，而Kubernetes在构建时假设这个网络已经存在私有云中的Kubernetes集群，不能假设网络已经存在。我们需要自己实现这个网络假设，打通不同节点上的Docker容器之间的互访，Kubernetes集群才能正常运行。同一个Pod中的多个容器过去常常通过环回网络(lo-127.0.0.1)进行通信。Pod之间的通信是通过OverlayNetwork网络，Pod和Service之间的通信是各个节点的iptables。或者lvsruleFlannel是CoreOS团队为Kubernetes设计的网络规划服务。简单来说，它的作用就是让集群中不同节点主机创建的Docker容器拥有整个集群唯一的虚拟IP地址。并且它还可以在这些IP地址之间建立一个覆盖网络（OverlayNetwork），通过这个覆盖网络，将数据包原封不动地投递到目标容器。不同情况下的网络通信方式同一个Pod内的内部通信：同一个Pod共享同一个网络命名空间和同一个Linux协议栈。不同Pod之间的通信：Pod1和Pod2在同一台Node主机上，docker0网桥直接将请求转发给Pod2，不通过Flannel转发。Pod1和Pod2不在同一台Node主机上，Pod的地址和docker0在同一网段，但是docker0网络和主机网卡是两个完全不同的IP网段，不同Node之间的通信只能是通过宿主机的物理网卡来使用的。将Pod的IP地址与所在Node的IP地址关联起来，通过这个关联，Pod之间就可以互相访问了。从Pod到Service的网络目前都是基于性能考虑，都是通过iptables或者lvs来维护和转发的。Pod到外网Pod要向外网发送请求，查找路由表，将数据包转发给宿主机的网卡。宿主机网卡完成路由选择后，iptables或lvs执行Masquerade将源IP地址更改为宿主机网卡IP。地址，然后向外网服务器发送请求。外网访问Pod通过Service服务对外提供Pod服务。ETCD为Flannel提供了指令：存储管理Flannel可以分配IP地址段资源来监控ETCD中每个Pod的实际IP地址，并在内存中为Pod节点建立和维护路由表。Pod的创建类型有很多种，以满足不同的目的ReplicationControllerReplicationController用于保证容器应用的副本数始终保持在用户定义的副本数，即如果一个容器异常退出，一个新的Pod会自动创建来替换它，如果异常容器过多会自动回收。ReplicaSet推荐在新版本的Kubernetes中使用ReplicaSet代替ReplicationController来管理Pod（相对更好的方式）。ReplicaSet和ReplicationController虽然没有本质区别，只是名字不同而已。唯一的区别是ReplicaSet支持用于标签过滤的集合选择器。虽然ReplicaSet可以独立使用，但一般推荐使用Deployment来自动管理ReplicaSet创建的Pod，这样就不用担心与其他机制不兼容的问题。比如ReplicaSet本身不支持滚动更新（rolling-update），但是使用Deployment部署原生支持。DeploymentDeployment为Pod和ReplicaSet提供了声明式的定义方式，用于替代之前使用ReplicationController方便快捷地管理应用。主要应用场景包括：滚动升级和应用回滚、扩容和缩容、暂停和恢复。HPAHPA仅适用于Deployment和ReplicaSet。在V1版本中，只支持根据Pod的CPU利用率进行扩容和缩容。在新版本中，它支持基于内存和用户自定义指标的动态扩展和收缩。StatefulSetStatefulSet是为了解决有状态服务的问题，相对于Deployment和ReplicaSet。其主要使用场景包括：稳定持久化存储、稳定网络识别、有序部署、有序收缩。DaemonSetDaemonSet确保所有或部分节点运行一个Pod副本。当一个Node加入集群时，会为其添加一个新的Pod。当一个Node从集群中移除时，这些Pod也会被回收。删除DaemonSet将删除它创建的所有Pod。使用DaemonSet的一个典型场景是在每个节点上运行日志收集、监控系统、集群存储等服务，只要新加入的节点需要运行该服务即可。JobJob负责批处理任务，只执行一次。它保证批处理任务的一个或多个Pod在返回成功之前成功完成。CrontJobCrontJob管理是一个基于时间的作业，即它在给定的时间点只运行一次，并在给定的时间点周期性地运行特定的任务。作者：Escape链接：https://www.escapelife.site/p...
