加入收藏 | 设为首页 | 会员中心 | 我要投稿 鞍山站长网 (https://www.0412zz.com/)- 应用安全、运维、云计算、5G、云通信!
当前位置: 首页 > 站长资讯 > 外闻 > 正文

云时代运维转型必读:容器运维模式的五大场景

发布时间:2019-08-16 03:05:56 所属栏目:外闻 来源:DBAplus社群
导读:其实我挺早就接触Docker和Kubernetes,时间大概在3、4年前吧,但是由于当时所在技术团队的业务模式所限制,还没有真正对容器云有技术需求,所以我更多还是以一种技术玩具的心态接触容器技术。 直到去年开始才正式接触基于容器云平台的技术架构,我从业务运

控制器(Controller),它充当View和Model的媒介,将模型和视图绑定在一起,包括处理用户的配置输入,以此修改Model。反过来,View需要知道Model中数据的变化,也是通过Controller来完成。除此之外,Controller还可以为应用程序协调任务,管理其它对象的生命周期。在k8s里面,最典型的Controller就是Deployment。

在上文中我们提到了k8s拥有很多API对象,而其中一部分是属于控制器类型的特殊对象,我们可以进入k8s的代码目录:kubernetes/pkg/controller/*,查看所有控制机类型的API对象,包含:deploymentjobnamespacereplicasetcronjobserviceaccountvolume 等等。

由于k8s的架构体系中,View不算是其核心的功能模块,我们这里重点关注Controller和Model的关系,代入k8s对象的话,我们以最典型的Deployment和Pod的关系,作为主要的研究对象。

我们回头看看文章连载前面的 Deployment 的yaml配置文件样例,可以划分为两大部分进行分析,配置文件的上半部分是属于控制器,下半部分是数据模型:

云时代运维转型必读:容器运维模式的五大场景

其实要深究起来,Deployment不是直接控制Pod,而是通过一个叫ReplicaSet的对象对Pod进行编排控制,所在在Pod的matadata里面会显示其 owerReference是ReplicaSet。

也就是说在控制器对象的范围内,也会进行功能的分层,因为不同的控制机之间,存在着可以复用的功能逻辑,比如对Pod的副本数控制。

那么这时候可以抽象出一层例如像ReplicaSet的对象,进行对Pod的副本控制,除了Deployment以外,也存在其他的控制器对象可以利用ReplicaSet进行对Model的控制。

云时代运维转型必读:容器运维模式的五大场景

基于这样的分层思想,我们在生产环境场景的所遇到的需求,可以将其控制逻辑都在控制器这一层进行实现。

比如无状态的Deployment和有状态的StatefuleSet,或者每个Node只有一个DeamonSet,尽管各自实现的功能各不相同,但是它们都是可以共用同一套Pod对象的逻辑,而差异的部分都封装在控制器层。

4、接口和实现

接口这个词广泛存在于各种技术文档中,到底接口是什么?

其实,狭义的接口是指代码编写的一个技巧,比如在Java语言里面,一个接口(interface)的特性是只定义了方法返回值、名称、参数等,但没有定义其具体的实现。

接口(interface)无法被实例化,但是可以被实现。一个实现(implements)接口的类(class),必须实现接口内所描述的所有方法,否则就必须声明为抽象类(Abstract Class)。

Java 接口实现:

  1. interface Animal {  
  2.     public void eat();  
  3.     public void travel();  
  4.  
  5. public class MammalInt implements Animal{ 
  6.    public void eat(){ 
  7.       System.out.println("Mammal eats"); 
  8.    } 
  9.    public void travel(){ 
  10.       System.out.println("Mammal travels"); 
  11.    } 
  12.    public int noOfLegs(){ 
  13.       return 0; 
  14.    } 
  15.    public static void main(String args[]){ 
  16.       MammalInt m = new MammalInt(); 
  17.       m.eat(); 
  18.       m.travel(); 
  19.    } 

以上是Java的接口类型,但除了狭义的接口,我们在开发各种软件中也会用到广义的接口。

接口对于调用方来说就是一种事先约定好的协议,它也许是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。

而在Kubernetes里面,其很多组件或者实现都采用了接口的形式,留给使用者非常灵活的扩展空间。

比如CRI CSI CNI 等等,都是Kubernetes留给其底层实现的接口方式。

Kubernetes作为云原生应用的最佳部署平台,已经开放了容器运行时接口(CRI)、容器网络接口(CNI)和容器存储接口(CSI),这些接口让Kubernetes的开放性变得最大化,而Kubernetes本身则专注于容器调度。

我们逐个了解一下以上3个接口,就可以对Kubernetes的实现思想有一定的感受,从而更深地理解其它类似的接口实现。

1)CRI (Container Runtime Interface,容器运行时接口)

Kubernetes其实不会直接和容器打交道,Kubernetes的使用者能接触到的概念只有pod,而pod里包含了多个容器。

CRI中定义了容器和镜像的服务的接口,因为容器运行时与镜像的生命周期是彼此隔离的。

(编辑:鞍山站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读