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

其实我挺早就接触docker和kubernetes，时间大概在3、4年前吧，但是由于当时所在技术团队的业务模式所限制，还没有真正对容器云有技术需求，所以我更多还是以一种技术玩具的心态接触容器技术。
直到去年开始才正式接触基于容器云平台的技术架构，我从业务运维和devops的角度来看，容器云平台与之前的物理机和虚拟机等iaas层基础上的运维模式有着非常大的差异。
1)master
区别于物理组件，逻辑组件是指在程序内的虚拟概念，例如运行在master的逻辑组件有kube-apiserver、kube-controller-manager、kube-scheduler。
kube-apiserver用于暴露kubernetes api。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。
kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。
kube-scheduler监视新创建没有分配到node的pod，为pod选择一个node。
这几个组件的用途不作特别展开，我们后面将详细聊聊apiserver。
2)node
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是值得我们去深入学习的，毕竟它战胜了几乎所有的编排调度工具，成为业内编排标准。
我们通过搭建容器云环境下的应用运行平台，并实现运维自动化，快速部署应用、弹性伸缩和动态调整应用环境资源，提高研发运营效率，最终实现自身的运维价值。


SEO可以带来什么好处？为什么越来越多的人都在做SEO?
延庆企业网站开发应该选择模板建站还是定制建站？
网站模板：模板建站的优缺点有哪些
网站优化文章的素材从哪里找
旅游小程序有什么开发价值？
为何网站建设用户体验普遍差？
怎样让网站更容易被百度抓取收录？
网站修改标题会影响搜索引擎的排名吗？