罗永浩|图文并茂!带你深度解析Kubernetes( 八 )

  • kubectl apply –f nginx.yaml


  • Kubernetes推荐使用:声明式对象配置(YAML) 。 kubectl replace执行过程是通过新的YAML文件中的API对象来替换原有的API对象 , 而Kubectl apply执行了一个对原有API对象的PATCH操作 。 除此之外 , YAML配置文件用于Kubernetes对象的定义 , 还会有以下收益:
    • 便捷性:不必添加大量的参数到命令行中执行命令 。
    • 灵活性:YAML可以创建比命令行更加复杂的结构 。
    • 可维护性:YAML文件可以通过源头控制 , 跟踪每次操作;并且对象配置可以存储在源控制系统中(比如Git);对象配置同时也提供了用于创建对象的模板 。
    • 开放插件
    Kubernetes的设计初衷就是支持可插拔的架构 , 解决PaaS平台使用不方便、不易扩展等问题 。 为了便于系统的扩展 , Kubernetes中开放了以下接口可对系统资源(计算、网络、存储)插件进行扩展 , 可分别对接不同的后端来实现自己的业务逻辑 。
    CRI(Container Runtime Interface):容器运行时接口 , 提供计算资源 。 CRI接口设计的一个重要原则是只关注接口本身 , 而不关心具体实现 , kubelet就只需要跟这个接口打交道 。 而作为具体的容器项目 , 比如Docker、rkt、containerd、kata container它们就只需要自己提供一个该接口的实现 , 然后对kubelet暴露出gRPC服务即可 。 简单来说 , CRI主要作用就是实现了kubelet和容器运行时之间的解耦 。

    CNI(Container Network Interface):容器网络接口 , 提供网络资源 。 跨主机容器间的网络互通已经成为基本要求 , K8S网络模型要求所有容器都可以直接使用IP地址与其他容器通信 , 而无需使用NAT;所有宿主机都可以直接使用IP地址与所有容器通信 , 而无需使用NAT 。 反之亦然 。 容器自己的IP地址 , 和别人(宿主机或者容器)看到的地址是完全一样的 。 K8S提供了一个插件规范 , 称为容器网络接口(CNI) , 只要满足K8S的基本需求 , 第三方厂商可以随意使用自己的网络栈 , 通过使用overlay网络来支持多子网或者一些个性化使用场景 , 所以出现很多优秀的CNI插件被添加到Kubernetes集群中 。
    CSI(Container Storage Interface):容器存储接口 , 提供存储资源 。 K8S将存储体系抽象出了外部存储组件接口 , 第三方存储厂商可以发布和部署公开的存储插件 , 而无需接触Kubernetes核心代码 , 同时为Kubernetes用户提供了更多的存储选项 。 例如:AWS、NFS、Ceph 。


    Kubernetes除了对系统资源可插件扩展外 , 也可以自定义CRD(Custom Resource Definition)来扩展API对象 , 同时也支持编写Operator对CRD进行控制 。 例如:对于一些有状态应用(etcd) , 可以定义新的CRD对象 , 并编写特定的Operator(本质上是新的controller)去实现控制逻辑 。
    Kubernetes的调度器Scheduler也是可以扩展的 , 可以部署自定义的调度器 , 在整个集群中还可以同时运行多个调度器实例 , 通过 pod.Spec.schedulerName 来选择具体指定调度器(默认使用内置的调度器) 。

    三、小结
    根据以上两个章节的阐述 , 对于文章开头的经典问题:如何才能有效的部署与管理应用?到Kubernets大放异彩的今天 , 已经给出了答案:
    • 应用部署与管理的问题 , 利用Docker+Kubernetes的方式已经完美解决 。