2.Kubernetes(K8S)架构2--Service,NameSpace,Volume等对象
文章目录
- Kubernetes(K8S)架构2
- K8S的面向对象
- Pod
- Service
- Label和Label Selector
- Label
- NameSpace
- Volum
- ReplicaSet
- ReplicaSet概念
- ReplicaSet应该有以下的特性和功能
- Deployment
- 简单的应用架构
- 网络架构
- Node IP
- Pod IP
- Cluster IP (Service IP)
Kubernetes(K8S)架构2
K8S的面向对象
K8S也是执行面向对象编程的概念
K8S中定义了一系列的资源, 这些资源可以抽象为对象, 同时可以通过K8S提供的 REST API 对对象进行操作, 对象实例化就相当于定义好资源并且运行, 比如定义一个Pod, 定义好包含那些容器,这些容器的镜像有又是什么,并且将Pod运行起来
K8S中的对象包括基础对象和高级对象
基础对象有Pod,Service,NameSpace(非linux的NameSpace)和Volume
同时为了进一步管理基础对象, 在基础对象的基础上又抽象出来一些高级对象, 比如控制器对象,
控制器对象有 ReplicaSet,Deployment,DaemonSet,StatefulSet和Job
Pod
Pod提供服务的基本单元, Pod面临问题有, Pod提供的服务供外部访问, Pod的建康状态检查
Service
- Service是用户真实访问的服务, Pod虽然提供服务但是Pod的IP是会发生改变的,比如Node宕机,
这个Pod会被负载到其他的Node重新运行, 这个时候Pod的IP就会发生改变, 如果用户直接访问Pod, 使用原来的IP就无法访问了, 为了解决Pod经常变动的问题, 就在Pod上面覆盖了一层 Service, 作为反向代理,在提供相同服务的一组Pod上面覆盖一层Service, 通过Service来访问Pod的服务. - 但是虽然Service的IP一般是不会改变, 但是Service的IP也有改变的时候,如果Service挂掉重新建立的时候新的Service的IP会接近注册到DNS中, 外部使用Service的名称经过DNS解析访问Service服务, 保证Service的IP发生变更后依然能够访问到 Service.
通过上面的手段就解决课服务发现的问题, 简单图例如下:
Label和Label Selector
Label和Label Selector 是K8S中很经典的一个设计, 可以用于筛选具有相同性质的一组资源对象.
例如,Label和Label Selector可以用于Service来访问一组提供相同服务的Service, 上面说到在一组提供相同服务的Pod上面覆盖一层Service, 用于用户来访问Pod服务. 那么Service就是通过Label和Label Selector 来访问这组服务的.
Label
K8S中可以给任何资源都定义对应的Label, 通常给具有相同特征的资源打上相同的标签, 例如给每组提供相同服务的Pod都定义相同的Label, 这样方便使用Label Selector来筛选对应的资源
Service选择对应的Pod逻辑如下:
.
NameSpace
这个NameSpace并非linux里面的NameSpace, 这里是K8S中的一个概念, 用于把 K8S 中的资源对象做隔离, 通过NameSpace可以将资源对象进行分组, 比如按照实例场景的的租户, 项目等分组, 并且能够限定每个组的资源.
Volum
Vloum(存储卷) 是上节讲的POD中的容器可以共享的的目录,
ReplicaSet
ReplicaSet概念
ReplicaSet可以定义用户所期望的资源的状况, 即用户通过ReplicaSet来声明自己所期望的资源的状态应该是怎么样的.
定义的内容有:
- Pod期待的副本数量
- 用户筛选Pod的Label Selector
- 当Pod的数量小于预期的时候, 用户创建Pod的模版
ReplicaSet应该有以下的特性和功能
- 通过定义一个RC来实现一个POD的创建过程和副本数量的控制
- ReplicaSet里面包含完整的POD定义的模版
- ReplicaSet是通过Label Selector来实现Pod副本的自动控制的
- 改变ReplicaSet里面的Pod的副本数量, 可以实现Pod的扩容或者缩融
- 改变ReplicaSet里面的Pod模版中镜像的版本可以实现POD的滚动升级
Deployment
Deployment 接収到用户的请求, 按照定义会创建出一个或者多个 Pod来.同时当Pod挂掉之后会重启创建一个Pod.以保证Pod的状态和用户期望的一致
简单图例如下
简单的应用架构
一个简单的应用架构图如下图所示
如上图所示, 用户直接要访问Nginx 是通过访问 Nginx的Service来实现的, 同Nginx 要访问应用的时候也是通过访问 应用的 Service来实现的, 不是直接访问应用的Pod, 应用访问 DB也是同样的原理.
同时每组服务的Pod都有对应的控制器资源来保证Pod正常运行,符合用户预定的期望.
网络架构
K8s中的三种网络
Node网络, 用于主机之间的通信, Pod网络表示Pod之间的通信, 包括跨主机的Pod, Service网络, Service之间的通信
同时三个网络野就有三种IP, Node IP,Pod IP和Cluster IP(Service IP)
Node IP
Node IP 是在集群中每个Node物理网卡的IP, 这个是一个真实的物理网络. 通过这个IP可以实现各个 Node之间的通信
Pod IP
是每个Pod的IP, 包括所有Node中的Pod, 因为不同Node的Pod是位于不用的Dcoker Engin中的, 所以不同Node的Pod要通信就要通过二级虚拟网络实现, 比如 Open vSwtich. 这样就能够实现不同Node的Pod直接通过 Pod IP 就能通信
可以参考: https://blog.csdn.net/qq_21047625/article/details/89683077
Cluster IP (Service IP)
Cluster IP 是一个虚拟的IP, 这个IP不存在对应的容器或者真实物理机, 所以他是无法ping 通的, 这个IP只是表明一个服务, 当K8S内部访问这个IP的时候就表示要访问这个IP对应的服务, K8S就会通过 Label Selector 找出对应的一组Pod, 并且通过算法让请求取访问对最合适的Pod IP, 所以Cluster IP 一般充当一个检索适用的Pod IP 的功能.
