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多退少补

万一另一个pod调度到另一个node上运行，但是调度到的node也宕机了，那么就少了一个副本，但是控制器会重新请求一个API Server重新创建一个新pod，API Server借助Scheeduler调度以后，找另外一个node然后把pod再起起来，到此为止又是符合人们期望的
滚动更新:
比如此前启动容器是靠所谓的1.0版的镜像启动的，后来做了有1.1的镜像，那么现在需要pod中的容器替换成1.1的镜像那么怎么办？可以做滚动更新，比如先创建新版本的pod然后再慢慢去除老的pod

像Deployment这种控制器还二级控制器叫HPA (HorizonlPodAutoscaler)
我们叫做水平pod自动伸缩器

解释:

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

服务发现:
此前我们配置个LAMP服务在Nginx端:我们通过配置文件写好对应后面那个M或者P的地址是什么,万一我们pod中的M、P发生变化了，地址是不是发生变化了，那么我们使用主机名可不可以，但是有没有想过新起一个pod主机名也变了，因为它已经是全新的pod了，大家想下应该怎么做？使用服务发现
客户端每次去访问后端的服务时，我们客户端不是直接访问的，因为它不知道后端是谁的，它需要先去找一个位置看看有没有这么一个服务

如果客户访问不到后端服务，定义为超时，那么这个摊位会自动移出该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中，dns自身也是个pod

K8S有三种网络:

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