K8S-K8S基础概念
为了能够统一管理集群上大量的资源,我们需要给Pod添加一些元数据信息
Pod 标签:Lable Key=value
而且在Key和value还有一定的限制,定义完后就可以使用所谓的标签选择器了,定义过滤条件来挑选符合我们的pod资源

我们知道在K8s上我们运行的容器以后,同一类容器,或者运行pod之后,同一类pod可能不止一个,既然如此,(1)当用户请求到达是我们如何去接入用户请求,到底给同一类的pod中哪一个pod来相应
(2)pod是需要所谓的控制器来管理pod的,尽量不要人手工去管理它

pod我们可以自己分类:
(1)自主式pod:自我管理的,创建以后,任然是提交给API Server,由API Server接收后借助Scheduler将其调度到指定的node节点,然后由node启动此节点,如果有pod中容器出现问题了,需要重启容器,那是由Keepalived来完成,但是如果节点故障了,pod也就消失了,所以,它有这样的坏处,没办法实现全局的调度,所以建议使用第二种pod
(2)控制器管理的pod,正是控制器这种机制的使用,使得在K8S上的集群设计中,pod完全就可以叫做有生命周期的对象,而后由调度器调度到集群中的某节点,运行以后,它的任务终止也就随着被删除掉,但是有一些任务,大家知道传统上有nginx、tomcat,它们是做为守护进程运行的,那么这种运行为pod容器的话,我们要确保它是时刻运行的,一旦出现故障我们要第一时间发现,要么是重建取代它,要么是重启,那么pod控制器就可以观测并实现

pod控制器早期的时候是:
RreplicationContrller,副本控制器
当我们启动一个pod时候,比如一个nginx pod,这个pod不够了,我可以再起一个副本,而后呢,控制器专门控制着同一pod资源,使得pod多退少补
K8S-K8S基础概念
万一另一个pod调度到另一个node上运行,但是调度到的node也宕机了,那么就少了一个副本,但是控制器会重新请求一个API Server重新创建一个新pod,API Server借助Scheeduler调度以后,找另外一个node然后把pod再起起来,到此为止又是符合人们期望的
滚动更新:
比如此前启动容器是靠所谓的1.0版的镜像启动的,后来做了有1.1的镜像,那么现在需要pod中的容器替换成1.1的镜像那么怎么办?可以做滚动更新,比如先创建新版本的pod然后再慢慢去除老的pod
K8S-K8S基础概念
像Deployment这种控制器还二级控制器叫HPA (HorizonlPodAutoscaler)
我们叫做水平pod自动伸缩器

解释:
K8S-K8S基础概念
容器承载不了这么多流量访问怎么办?所以我们需要加更多的pod资源了,到底应该加几个呢?所以HP控制器可自动监控着,自动进行扩展,比如他会自动分析现在的cpu、内存利用率有多高,确保平均低于百60%,那么一计算,需要额外加两个,那么就HPA自动给加上两个,一旦小了也可以减少,可以确保有几个存在

服务发现:
此前我们配置个LAMP服务在Nginx端:我们通过配置文件写好对应后面那个M或者P的地址是什么,万一我们pod中的M、P发生变化了,地址是不是发生变化了,那么我们使用主机名可不可以,但是有没有想过新起一个pod主机名也变了,因为它已经是全新的pod了,大家想下应该怎么做?使用服务发现
客户端每次去访问后端的服务时,我们客户端不是直接访问的,因为它不知道后端是谁的,它需要先去找一个位置看看有没有这么一个服务
K8S-K8S基础概念
如果客户访问不到后端服务,定义为超时,那么这个摊位会自动移出该pod注册的信息,新建的pod会在摊位会注册服务信息

pod是有生命周期的,一个pod随时可能离去,随时也可能创建新的pod,假如它们提供的是同一种服务,我们客户端是没有办法采用固定的手段来访问这个pod的,因为pod是随时变化的,无论你是使用主机名还是ip地址都随时会替换掉,那怎么办?这就需要用到服务发现机制了,那么K8S为同一类pod或同一组pod与客户端之间添加了中间层这个中间层是固定的,这个中间层就叫做service,service只要不删除,它的地址是固定的,名称服务名也是固定的,这个服务不但能够提供一个稳定的访问入口还能起到调度的做作用,就算pod宕机了创建新的pod service会自动把pod关联进来,大家知道pod有一个固定的元数据,叫标签,它就是通过标签来关联的,关联后能够自动探测pod的IP地址和服务端口
而在K8S当中,service可不是什么应用程序,也不是什么组件,它只不过是iptables的DNAT规则

AddOns:附件:dns只是它们当中的一个
改附件能够动态删除动态变动:比如你把service名称改了,它会自动触发dns中的解析记录,把解析记录名称也改了,客户端访问的时候,dns解析的是service的地址而不是pod的地址
service是端口代理,大家知道是DNAT实现,但是后面很多pod资源,所以DNAT认为是多目标调度了,对Linux来讲iptables已经把负载均衡的功能主要交给IPVS来实现,所以调度效果上是不太近人意
所以在K8S的1.11版中,已经把iptables规则改为了IPVS规则,也就是说你每创建一个service的时候就相当于创建了一个IPVS规则

用Nginx+tomcat+mysql的例子类比所有的k8s集群架构:
K8S-K8S基础概念
K8S中,dns自身也是个pod
K8S-K8S基础概念

K8S有三种网络:
K8S-K8S基础概念

本文摘引至:https://www.cnblogs.com/hanhuibk/p/9645962.html
个人觉得写的很好,易懂,值得收藏。