服务模型图
服务进程
假设现在有五台机器，我们给其中的三台安装了Mysql，那么这三台机器上就有了Mysql的服务进程，我们把三个服务进程叫做K8s的一个Service。在实际的应用中，通过在一台机器上部署多个docker实例来达到这种效果。
服务隔离
然后给Service贴个标签，比如起个名字“MySQL_XXX”。那么，在k8s容器中，它就是唯一确定的一个服务，也就是k8s的一个pod对象，我们通过虚拟ip+端口号的方式可以访问到这个Servidce。k8s通过贴标签的方式实现了应用间的隔离。
服务通信
在k8s内部，Service的服务进程通过socket通信的方式对外提供服务。所以，k8s服务一定是实现了某个具体业务的TCP进程。
故障恢复
即使在使用的过程中，某个服务进程挂掉了或者重启了，或者转移到了其他的机器上，都不会影响我们对服务的正常调用，因为这个Service本身一单创建就不会再变化了，我们也不用为了服务ip地址的变化而头疼了。
集群管理
k8s将集群中的机器划分为一个master节点和一堆工作节点node，
其中，master节点运行着集群管理相关的一组进程kube-api-server、kube-controller-mananger和kube-scheduler，这些进程实现了整个集群的资源管理、pod调度，弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。
node作为集群中的一个工作及诶单那，运行真正的应用程序，在node上k8s管理的最小运行单元是pod。node上运行着k8s的kubelet、kube-proxy服务进程，这些服务进程负责pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。
服务扩容和升级
只需为需要扩容的Service关联的pod创建一个Reapplication
Controller（简称RC），则改Service的扩容以及后续的升级问题将迎刃而解。在一个RC定义文件中包含3个关键信息：目标pod的定义、目标pod需要运行的副本数量（replicas）、要监控的目标pod标签（Label）。在创建好RC后，k8s会通过RC中定义的Label筛选出对应的pod实例并实施监控器状态和数量。如果实例数量少于定义的副本数量，则会根据RC中定义的pod模板来创建一个新的pod，然后将pod调度到合适的node上启动执行，直到pod实例的数量达到预定目标，这个过程完全是自动化。
核心概念
Master
k8s的管理节点，负责管理集群，提供集群的数据访问入口，拥有Etcd存储服务（可选）。运行Api Server进程，Controller
Manager服务进程及Scheduler服务进程，关联工作及节点Node。
kubernetes Api Server**：提供Http
Rest接口的关键服务进程，是kubernetes里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程。
kubernetes Controller Manager**：是kubernetes Controller
Manager是kuberbetes所有资源对象的自动化控制中心；
kubernetes Schedule**：是负责资源调度的（pod调度）进程。
Node
Node是kubernetes集群架构中运行pod的服务及诶点。Node是kubernetes集群操作的单元，用来成单被分配pod的运行，是pod的宿主机。关联Master管理节点，拥有名称和ip，系统资源信息。运行docker engine服务，守护进程kunelet以及负载均衡器kube-proxy。
kubelet：服务队pod对于容器的创建，启停等任务；
kube-proxy：实现kubernetes
Service的通信与负载均衡的重要组件； Docker Engine(Docker):负责本机容器的创建和管理工作。
Node节点可以在运行期间动态增加到kubernetes集群中，默认情况下，kubelete会向master注册自己，这也是Kubernetes推介的node管理方式，kubelet进程会定时向master汇报自身情报，如操作系统，docker版本，Cpu和内存，以及哪些pod在运行等等，这样master可以在获知每个node及诶点的资源使用情况，并实现高效负载均衡的资源调度策略。
Pod
运行在node节点上，若干相关容器的组合。pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间，ip地址和端口，能够通过localhost进行通信。pod是kubernetes进行创建，调度和管理的最小单位，他提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个pod可以包含一个容器或者多个相关容器。
pod其实有两种类型，普通pod和静态pod，后者比较特殊，它并不存在kubernetes村村中，而是存在在某个具体的node上的具体文件，并且只在此node上启动。普通pod一单被创建，就会被放入etcd存储中，随后会被kubernetes master调度到某个具体的node上进行绑定，随后改pod对应的node上的kubelet进程实例化成一组相关的docker容器并启动起来。在默认情况下，当pod里某个容器停止时，kubernetes会自动检测到这个问题并且重启这个pod（重启pod里所有进程）。如果pod所在的node宕机，则会将这个node上的所有pod重新调度到其他节点上。
Repplication Controller
Repplication Controller用来管理pod的副本，保证集群中UC妮子啊指定数量的pod副本。集群中副本数量大于指定数量，则会停止多余容器数量。反之，则会启动少于指定数量个数的容器。保证数量不便，Repplication Controller是实现弹性绳索，动态扩容和滚动升级的核心。
Service
Service定义了Pod的逻辑接和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod。用户不需要了解后台Pod是如何运行。
外部系统访问Service的问题，需要弄明白kubernetes的三种Ip问题：
Node ip：Node节点的IP地址 Pod ip：Pod的IP地址 Cluster ip： Service的ip地址首先，Node IP是kubernetes集群中节点的物理网卡IP地址。所有属于这个网路ode服务器之间都你能通过这风格网络直接通信。
Pod IP是每个Pod的ipo地址，它是Docker Enhine根据docker网桥的up地址段进行分配的，通常是虚拟二层网络。
Cluster Ip是一个虚拟ip，更像一个伪造的ip网络。
Label
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置等管理工作。
一些常用的Label如下：
版本标签："release":"stable","release":"canary"......
环境标签："environment":"dev","environment":"qa","environment":"production"
架构标签："tier":"frontend","tier":"backend","tier":"middleware"
分区标签："partition":"customerA","partition":"customerB"
质量管控标签："track":"daily","track":"weekly"
Label相当于我们熟悉的标签，给某个资源对象定义一个Label就相当于给它大了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。
kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程
kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡
通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性。
参考博客：https://blog.csdn.net/weixin_43277643/article/details/83382532