其实我挺早就接触Docker和Kubernetes，期间大略在3、4年前吧，但是由于过后所在技术团队的业务形式所限度，还没有真正对容器云有技术需求，所以我更多还是以一种技术玩具的心态接触容器技术。
直到去年开局才正式接触基于容器云平台的技术架构，我从业务运维和DevOps的角度来看，容器云平台与之前的物理机和虚构机等IaaS层基础上的运维形式有着十分大的差异。
依据这段期间的运维阅历，我尝试总结一下某些容器云的运维方法的独特特性，并将其称为“容器运维形式”，繁难百度谷歌了一下，没有这个名词，宿愿是我的独创:)
这个名词灵感来自软件工程的“设计形式”，设计形式(DesignPattern)是一套被重复经常使用、少数人通晓的、经过火类的、代码设计阅历的总结。经常使用设计形式的目的：为了代码可重用性、让代码更容易被他人了解、保证代码牢靠性。设计形式使代码编写真正工程化;设计形式是软件工程的基石头绪，似乎大厦的结构一样。
而“容器运维形式”，指的是由DevOps(题外话：DevOps、SRE、SA、运维等等，其实都差不多是同一个意思，业界青睐创一个新的名词来替代运维，关键是为了区分自己和一些低端系统保养人员)在日常运维容器化名目的一些阅历总结，为了区别于传统的物理机、虚构机的运维套路，而演绎进去的容器运维方法。
回忆过去
从大略10年前，大家都是以【自建IDC】+【物理主机】的方式启动消费环境基础架构的树立。
而后继续到大略5年前，私有云技术和私有云的兴起，让少量中小型企业缩小对物理设备资源树立的人力和资金投入，可以专一于业务研发和运营。
最后到大略3、4年前，容器技术Docker和以Kubernetes为代表的容器编排技术的崛起，以及微服务技术的同步遍及，宣告了容器云平台的来临。
而理想上，以Kubernetes为首的相关周边名目，曾经成为了容器云畛域的首选规范，所以绝大局部技术团队假设如今须要选型容器编排体系，可以无脑选k8s了。
需求的基本——运行交付
在传统裸机(bare metal)或虚构化的时代，当开发团队将代码交付给运维启动消费环境中部署，但是它却未能反常上班时，应战就出现了。
“运转环境不分歧”、“没有装置相关依赖软件”、“性能文件不一样”等等曾经成了开发和运维沟通的习用语。
在传统的开发场景中，开发和测试团队经常使用的是与消费环境不同的基础设备，虽然做到了代码和性能解耦，但是在运转环境的转换中，依然会失掉像前面所述的团队单干和环境依赖疑问。
而贯通软件生命周期共享相反的容器镜像是容器化带来的最大好处，它简化了开发与运维团队之间的单干相关。
由于本地开发/测试主机和消费环境的不分歧以及运行程序打包部署的环节，不时是让研发和运维纠结的难题，但有了容器之后，由于容器镜像里打包的不只是运行，而是整个操作系统的文件和目录，即其运转所需的一切依赖，都能被封装一同。
有了容器镜像的打包才干之后，这些运行程序所需的基础依赖环境，也成为了这个运行沙盒的一局部，这可以给这个运行包赋予这样的才干：无论在开发、测试还是消费环境运转，咱们只要要解压这个容器镜像，那么这个运行所需的一切运转依赖都是存在的、分歧的。
假设相熟Docker容器技术原理的话，咱们知道它关键由Linux内核的Namespace和CGroups以及rootfs技术隔离进去一种不凡进程。
把Docker描画为一个房子的话，Namespace构成了四面墙，为PID\NET\MNT\UTS\IPC等资源启动隔离;CGroups构成了它的天花板，限度了对系统资源的占用;而rootfs是其地基，是经过copy-on-write机制构成的分层镜像，也是开发者最为关心的运行信息的传递载体。
作为开发者，他们或许不关心由前两者构成的容器运转时的环境差异，由于真正承载容器化运行的传递载体，是这个不变的容器镜像。
在Docker技术的遍及后不久，为了整个完整的DevOps链条的买通，包括CI/CD、监控、网络、存储、日志搜集等消费环境的刚需，以及整个容器生命周期的治理和调度，以Kubernetes为首的容器编排体系也作为下层修建也迎来了一波极速的增长。冷静器到容器云的变质，标记着容器运维时代的来临。
容器运维形式的关键场景剖析
1、申明式 vs 命令行
咱们知道Kubernetes是经过yaml文件(样例如上所示)来对其API对象，如Deployment、Pod、Service、DaemonSet等启动希冀形态的描画，而后k8s的控制器有一套形态调谐的机制让各种API对象按要求所述的形态运转。由于这样一套运转机制的存在，所以使得k8s和过往运维经常出现的命令行，也包括脚本式的运转方式有着很大的差异。
深度经常使用过puppet的运维工程师或许会比拟分明两者的区别，puppet也是一套基于申明式机制的性能治理和形态治理的工具。在没有puppet之前，运维工程师青睐用繁难的shell、python脚本对泛滥主机启动一致的软件装置、性能治理，但随着主机数量增多和性能项的递增，命令行式的性能治理往往出现各种缺点。如形态不分歧、历史版本无法回滚、性能没有幂等性、须要很多形态判别才干口头最终的操作等等。
而申明式的性能治理方法，可以规避以上弊病，要素如下：
当咱们确认了一个版本yaml性能文件后，示动向k8s的Kube-Controller-Manager提交了咱们所希冀的对象形态信息，而后k8s经常使用patch的方式对API对象启动修正。而申明式API是k8s名目编排才干的**所在，它可以在无需干预的状况下对api对象启动增删改查，成功对“希冀形态”和“实践形态”的reconcile环节。
以咱们罕用的deployment对象为例。
1)方式一
2)方式二
初次创立经常使用 create ，修正yaml经常使用edit，而后用replace使之失效。
k8s对这两种机制的处置方法是齐全不同的，前者是申明式，后者是命令式。
两者的结果虽然都是触发滚动更新，但是前者是对原有API对象打patch，后者是对象的销毁和交流。前者能一次性处置多个yaml性能变卦的写操作并具有相反性能项的merge才干，后者只能一一处置，否则有抵触的或许。
所以，咱们只要要确认yaml文件的版本，一概经过 kubectl apply命令启动口头，无需再思索第一步创立、第二步修正、第三步交流之类的命令行。那么咱们一致用apply命令，可以经过history命令启动回溯版本，也可以保证apply的结果的幂等性等等。
经常使用申明式只要要描画最终所需的形态，无需用户关心过多的成功流程和细节，没有像命令行式的那么多上下文相关或许运转环境依赖，甚至可以由开发人员间接编写，运维启动codereview即可。特意在经常使用Kubernetes这样的容器编排工具，愈加要深入了解和灵敏运用申明式的运维形式。
2、API对象
Kubernetes少量的API对象的存在是造成其运维方法和传统系统层运维有区别较大的关键要素之一。
假设咱们要深化了解k8s，则须要了解一些它**的API对象，才干更好地理解这个容器的运转系统。假设把容器了解成一种不凡带有资源隔离、资源限度的进程，那么Pod对象是一组进程组，最后，k8s是运转泛滥无关联的进程组(Pod)的操作系统。
这一层操作系统运转在PaaS层，比咱们传统运维的Linux系统所在的IaaS层要高一层。
而咱们无了解这个在PaaS层的k8s对象的概念时，须要一些面向对象的编程思想，会让整个思绪梳理地愈加明晰。
所谓的面向对象，即在编码环节中设定一切事物皆对象，经过面向对象的方式，将理想环球的事物形象成对象，理想环球中的相关形象成类、承袭，协助人们成功对理想环球的形象与数字建模。
经过面向对象的方法，更利于用人了解的方式对复杂系统启动剖析、设计与编程。同时，面向对象能有效提高编程的效率，经过封装技术，信息机制可以像搭积木的一样极速开收回一个全新的系统。
面向对象是指一种程序设计范型，同时也是一种程序开发的方法。对象指的是类的汇合。它将对象作为程序的基本单元，将程序和数据封装其中，以提高软件的重用性、灵敏性和裁减性。
在系统层运维时刻，咱们关注的有CPU、内存、IO等配件对象，以及软件装置卸载、系统服务启停、环境变量、内核版本等软件对象等等，就足以了解和把控整个操作系统运转环境。
了解这些对象可以当成是一种面向环节的思想，由于最后操作系统的设计就是过后的计算机大牛们经过面向环节的思想所写进去的，所以系统很多组成概念毋庸要面向对象思想就可以了解。
妇孺皆知，Kubernetes是依据谷歌外部运转多年的Borg名目的架构体系所发明进去，所以它具有天生的名目架构前瞻性。普通的开源名目是通常基础走在工程运行的前面，比如docker+swarm为代表，都是理想运行中遇到什么需求，就新增一特性能，缓缓从一个独自容器docker再到了具有基本编排才干的swarm。反观Kubernetes，是一套自顶向下的架构设计，简直能适配一切的运行架构形式，应答什么web-db、lb-web-redis-db、db-master-slave之类的经常出现架构基本不在话下。
再回到Kubernetes的API对象，k8s经常使用这些API对象来描画一个集群所希冀的运转形态。
通常一个Kubernetes对象蕴含以下信息：须要运转的运行以及运转在哪些Node上、运行可以经常使用哪些资源、运行运转时的一些性能，例如正本数、重启战略、更新以及容错性等等。
经过上图可见API对象种类十分多，其实咱们应该先重点把握最**的Node、Pod、Deployment、RS、Service、Namespace，以及它们之间的相关，这里就不详述了，请参考相关文档。
3、控制器形式
在说Kubernetes的控制器形式之前，咱们先看看软件架构中十分经常出现的MVC形式，即Model(模型)、View(视图)、Controller(控制器)。
1)模型(Model)
用于封装与运行程序的业务逻辑相关的数据以及对数据的处置方法。“ Model”有对数据间接访问的权势，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model不关心它会被如何显示或是如何被操作。但是 Model 中数据的变动普通会经过一种刷新机制被发布。为了成功这种机制，那些用于监督此 Model 的 View必定事前在此 Model 上注册，从而，View 可以了解在数据 Model 上出现的扭转。比如：观察者形式(软件设计形式)。
2)视图(View)
能够成功数据有目的的显示(通常上，这不是必需的)。在 View 中普通没有程序上的逻辑。为了成功 View 上的刷新性能，View须要访问它监督的数据模型(Model)，因此应该事前在被它监督的数据那里注册。
3)控制器(Controller)
起到不同层面间的组织作用，用于控制运行程序的流程。它处置事情并作出照应。“事情”包括用户的行为和数据 Model 上的扭转。
MVC 形式强调职责分别，即视图和数据模型的分别，并应用控制器来作为这两者的逻辑控制的中介，使之具有逻辑复用、松懈耦合等优势。
数据模型(Model)，它描画了“运行程序是什么”，用于封装和保留运行程序的数据，同时定义操控和处置该数据的逻辑和运算。而且，Model通常是可以复用的。
一个良好的MVC运行程序应该将一切关键的数据都封装到Model中，而运行程序在将耐久化的数据(文件、数据库)加载到内存中时，也应该保留在Model中。
由于Model自身就代表着业务的特定数据对象，而在k8s外面，典型的Model就是Pod。
视图(View)，它是展现给用户的界面，这个不用多说。这个在k8s的运行不多，例如kubectl的信息输入或许Dashbord等，都可以算是一种View的运行。
控制器(Controller)，它充任View和Model的媒介，将模型和视图绑定在一同，包括处置用户的性能输入，以此修正Model。反上来，View须要知道Model中数据的变动，也是经过Controller来成功。除此之外，Controller还可以为运行程序协调义务，治理其它对象的生命周期。在k8s外面，最典型的Controller就是Deployment。
在上文中咱们提到了k8s领有很多API对象，而其中一局部是属于控制器类型的不凡对象，咱们可以进入k8s的代码目录：kubernetes/pkg/controller/*，检查一切控制机类型的API对象，蕴含：deployment\job\namespace\replicaset\cronjob\serviceaccount\volume等等。
由于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)，必定成功接口内所描画的一切方法，否则就必定申明为形象类(AbstractClass)。
Java 接口成功：
以上是Java的接口类型，但除了狭义的接口，咱们在开发各种软件中也会用到狭义的接口。
接口关于调用方来说就是一种事前商定好的协定，它兴许是一些预先定义的函数，目的是提供运行程序与开发人员基于某软件或配件得以访问一组例程的才干，而又无需访问源码，或了解外部上班机制的细节。
而在Kubernetes外面，其很多组件或许成功都驳回了接口的方式，留给经常使用者十分灵敏的裁减空间。
比如CRI \ CSI \ CNI 等等，都是Kubernetes留给其底层成功的接口方式。
Kubernetes作为云原生运行的低劣部署平台，曾经放开了容器运转时接口(CRI)、容器网络接口(CNI)和容器存储接口(CSI)，这些接口让Kubernetes的放开性变得最大化，而Kubernetes自身则专一于容器调度。
咱们一一了解一下以上3个接口，就可以对Kubernetes的成功思想有必定的感触，从而更深地理解其它相似的接口成功。
1)CRI (Container Runtime Interface，容器运转时接口)
Kubernetes其实不会间接和容器打交道，Kubernetes的经常使用者能接触到的概念只要pod，而pod里蕴含了多个容器。
CRI中定义了容器和镜像的服务的接口，由于容器运转时与镜像的生命周期是彼此隔离的。
当咱们在Kubernetes里用kubectl口头各种命令时，这一切是经过Kubernetes上班节点里所谓“容器运转时”的软件在起作用。大家最相熟的容器运转时软件当然是Docker，但是Docker只是Kubernetes允许的容器运转时技术的一种。
为了让Kubernetes和睦某种特定的容器运转时(Docker)技术绑死，而是能无需从新编译源代码就能够允许多种容器运转时技术的交流，和咱们面向对象设计中引入接口作为形象层一样，在Kubernetes和容器运转时之间咱们引入了一个形象层，即容器运转时接口。就算Docker不再盛行了，甚至有了Eocker、Focker等等，就可以经过CRI接口无缝地融入Kubernetes体系。
2)CSI (Container Storage Interface，容器存储接口)
CSI 代表容器存储接口，CSI 试图树立一个行业规范接口的规范，借助 CSI 容器编排系统(CO)可以将恣意存储系统泄露给自己的容器上班负载。
相似于 CRI，CSI 也是基于 gRPC 成功。CSI 卷类型是一种 in-tree(即跟其它存储插件在同一个代码门路下，随 Kubernetes的代码同时编译的) 的 CSI 卷插件，用于 Pod 与在同一节点上运转的外部 CSI 卷驱动程序交互。部署 CSI 兼容卷驱动后，用户可以经常使用 csi作为卷类型来挂载驱动提供的存储。
3)CNI (Container Network Interface，容器存储接口)
CNI(Container NetworkInterface)是CNCF旗下的一个名目，由一组用于性能Linux容器的网络接口的规范和库组成，同时还蕴含了一些插件。CNI仅关心容器创立时的网络调配，和当容器被删除时监禁网络资源。
Kubernetes 网络的开展方向是宿愿经过插件的方式来集成不同的网络打算， CNI就是这分歧力的结果。CNI只专一处置容器网络衔接和容器销毁时的资源监禁，提供一套框架，所以CNI可以允许少量不同的网络形式，并且容易成功。
CNI的接口中包括以下几个方法：
有四个方法：增加网络、删除网络、增加网络列表、删除网络列表。
5、Master-Node形式与Api-server
Kubernetes有几个**组件：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CRI(普通是docker)等等。
它们区分是运转在Master或许Node节点上方，我把Master和Node称为物理组件，由于它们是运转于物理环境的，如物理机或许虚构机。其中Master提供集群的治理控制中心，而Node是真正接受口头义务的上班节点，可以拟人化地理解为：Master是用人经理，Node是上班人员。
而Etcd是用于存储性能信息或许其余须要耐久化的数据，独立于Master和Node节点，普通也是三正本的方式运转。
区别于物理组件，逻辑组件是指在程序内的虚构概念，例如运转在Master的逻辑组件有kube-apiserver、kube-controller-manager、kube-scheduler。
kube-apiserver用于泄露Kubernetes API。任何的资源恳求/调用操作都是经过kube-apiserver提供的接口启动。
kube-controller-manager运转治理控制器，它们是集群中处置惯例义务的后盾线程。逻辑上，每个控制器是一个独自的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运转。
kube-scheduler监督新创立没有调配到Node的Pod，为Pod选用一个Node。
这几个组件的用途不作特意开展，咱们前面将详细聊聊Apiserver。
Node是Kubernetes中的上班节点，最开局被称为minion。一个Node可以是VM或物理机。每个Node(节点)具有运转pod的一些必要服务，并由Master组件启动治理。
而后引见运转于Node节点的组件：kubelet、kube-proxy、CRI(普通是docker)。
kubelet是关键的节点代理，它会监督已调配给节点的pod，详细性能如：装置Pod所需的volume;下载Pod的Secrets;Pod中运转的docker(或experimentally，rkt)容器;活期口头容器肥壮审核等等。
kube-proxy经过在主机上保养网络规定并口头衔接转发来成功Kubernetes服务形象。
Docker等容器运转时，作用当然就是用于运转容器。
关于以上的Kubernetes的Master和Node的节点形式，在很多允许散布式架构的软件中都是相似的，如Hadoop等。他们的Master节点往往须要有3个以上，以成功高可用架构。很多软件架构也采取了这样的设计方式，都是为了消费环境所需的高可用性服务。
3)Api-server
前面引见过Master和Node，它们之间从Master(apiserver)到集群有两个关键的通讯门路。第一个是从Apiserver到在集群中的每个节点上运转的kubelet进程。第二个是经过Apiserver的代感性能从Apiserver就任何Node、pod或service。
所以说Apiserver关于Master-Node形式来说是十分关键的沟通桥梁。
从Apiserver到kubelet的衔接用于失掉pod的日志，经过kubectl来运转pod，并经常使用kubelet的端口转发性能。这些衔接在kubelet的HTTPS终端处中断。
从Apiserver到Node、Pod或Service的衔接默以为HTTP衔接，因此不需启动认证加密。也可以经过HTTPS的安保衔接，但是它们不会验证HTTPS端口提供的证书，也不提供客户端凭据，因此衔接将被加密但不会提供任何诚信的保证。这些衔接无法以在不受信赖/或公共网络上运转。
总结
从过去的【单体式运行+物理机】，到如今【微服务运行+容器云】的运转环境的改革，须要运维工程师同步扭转以往的运维技术思想。新技术的运行，会引发更深档次的思索，深化了解容器之后，咱们会人造而然地去学习业务最干流的编排工具——Kubernetes。
Kubernetes前身是谷歌的Borg容器编排治理平台，它充沛表现了谷歌公司多年对编排技术的最佳通常。而容器云字面意思就是容器的云，实践指的是以容器为单位，封装环境、提供构建、发布、运转散布式运行平台。
而运维工程师在面对业界更新迭代极快的技术潮流下，须要选定一个方向启动深耕，无疑，Kubernetes是值得咱们去深入学习的，毕竟它打败了简直一切的编排调度工具，成为业内编排规范。
咱们经过搭建容器云环境下的运行运转平台，并成功运维智能化，极速部署运行、弹性伸缩和灵活调整运行环境资源，提高研发运营效率，最终成功自身的运维价值。
作者引见
温峥峰，小鹏汽车互联网中心运维初级经理，专一于运维智能化、DevOps通常、运维服务体系树立与容器运维时代下的价值开掘。知乎专栏：HiPhone运维之道。