岗位学习教程

在云原生时代下，以应用上容器云推进企业 IT 技术架构转型升级已得到广泛共识，在企业开展应用上云中，标准化一定是规模上云的基础，而知识库的目的，就是建立标准和规范，同时也是每个企业推进应用上容器云的经验宝库，可有效将容器云基础设施与开发人员进行链接，为企业架构转型提速增效。本课程主要讲解知识库建设的通用性原理，围绕知识生产到消费再到知识再生产的完整闭环阐述知识库的核心建设过程，并根据应用上容器云特点提出业务以及技术上的一些建议，希望对有计划建设上云知识库的企业提供参考。

本课程主要介绍企业在云原生场景下应用上云的评估标准和面向云原生体系的应用架构设计方案。在构建云原生架构的过程中，主要包括应用侧的微服务化设计、容器化改造，云原生侧的不可变基础设施构建，同时也会涉及到企业工程师文化打造、全流程 DevOps 工具链的研发。在进行企业云原生应用改造过程中，主要需要考虑应用本身架构模式、企业存量系统自主掌控程度、数据中心云原生运维体系等情况综合判断上云的可行性。

随着容器化、Kubernetes、微服务等技术和架构在 IT 基础架构和应用架构中逐步落地，显著加快了应用程序的交付速度，帮助企业提升在数字经济时代的竞争力。然而，在实现敏捷交付的同时，也带来了代码 Bug 增加，系统架构复杂和可观测性下降、故障定位困难等一系列问题。本文旨在探讨在应用交付过程中（包括 CICD 流程）的应用交付的相关标准和指标，用来指导如何提升在敏捷交付的过程中应用系统的质量和健壮性。

本章节主要从容器云平台上下游链路的应急安全和容器云平台的规划思路和应急管理两个方面进行展开。在进行本章节的编写之初，笔者考虑到单纯的应急预案过于虚化，而实际的问题剖析和常见故障处理由《容器云平台突发情况的排查和处理》进行承接，因此结合了容器云平台的架构、安全的规划思路，到关键的核心使用场景的应急管理进行讲解，由点到面的对全局进行讲解。读者可以根据容器云平台上下游链路的应急安全来了解到上下游链路的关系，以及对基础设施资源层、容器管理调度层、容器引擎层、服务层、应用层、基础组件层、中间件层、镜像层的应急和安全的思路有权限的了解。在第二小节中，读者可以更详细的从全局出发，以平台的定位开始，从镜像和镜像仓库、微服务和api管理、应用管理到最后的容器内外部访问，结合理论实际，到规划能力和应急管理思路对容器云平台有完善的了解，在遇到问题或瓶颈时，通过完善的架构和设计理念，更高效的解决问题，保证业务连续性。

本章节重点介绍了容器云的两大核心引擎，Docker容器引擎和Kubernetes编排引擎的对外服务接口和使用方式，在本章的前言部分，通过对Api和Rest的介绍，让读者可以清晰了解对外接口的概念和解释，在正文部分，分别对Docker和Kubernetes的对外接口种类和使用场景进行描述，并通过案例和输出结果的方式让读者更容易理解，需要注意的是，Kubernetes的对外接口存在版本和Groups的使用方式和选择。Docker的Api中比较常见的有Registry、Hub、Remote，Kubernetes的Api主要包括了对资源分类的查询、对资源对象的查询、对资源进行操作。在本章节的最后，以两个较为详细的范例供读者进行搭建Dome进行模拟。通过对本章节的学习，读者可以对容器云平台的对外接口标准、种类和使用方式有较为全局的了解，在后续的自动化和智能化运维过程中，可以通过接口的方式嵌入到第三方系统和平台，更简单和便捷的维护容器云平台。

万物互联时代，企业正在面临着日益严峻的网络安全风险，不断升级的网络攻击、数据泄漏等安全挑战。 企业需要满足数字化转型的期望，实现快速交付和扩大数字业务增长的成功需求。企业 扩展数字化业务时，需要不断投资并引入容器、微服务架构等云原生技术，构建崭新的数字平台，并制定相应的数字发展战略，帮助企业加速数字化创新，以保持竞争中的领先地位。 云原生应用作为数字业务应用的最佳载体，伴随着企业数字化转型，被越来越多的企业用户所接受。企业基于云原生技术构建自己的智能混合云数字平台，保持企业在数字经济时代的创新竞争力。容器技术具有行业标准、灵活与轻量的特性，支持微服务架构，提高开发运维效率，实现数字业务应用的快速迭代，并能够在异构的云基础设施之间轻松迁移。Gartner 最终用户调查研究显示，中国用户对容器技术的热情高于世界其它市场。汽车、金融、制造、媒体、零售等很多企业都已经将容器运行在了生产环境。通过本章节的学习，能够快速了解在当前容器云平台已经运行的情况下需要遵循的云原生安全标准与设计。

本章节分成两部分，第一部分主要介绍相关概念和方法论，第二部分将结合容器技术具体探讨如何在容器环境下做性能测试、分析。 理论来源于实践又服务于实践，在笔者多年的IT经验中，性能问题一直是相对复杂的高阶问题，从性能测试到分析再到优化，考验的是工程师的综合IT技能。一个系统整体的性能牵扯到方方面面，硬件配置、网络配置、操作系统、中间件、应用架构、代码质量等等都会影响到系统的整体性能。初入性能领域的工程师可能感觉到无从下手。本章第一部分内容主要就是介绍相关性能测试、分析、优化的方法论。希望通过方法论的学习，可以帮助工程师在复杂纷乱的环境下明确性能目标，制定合理可行的性能测试计划，有针对性的进行性能分析，发现系统真正的性能瓶颈，并最终能够进行有效的性能优化。 实践是检验真理的唯一标准，只有通过大量的实践，才能完成从量变到质变的转变过程，从技术小白转变为领域专家。本章第二部分就是以简单的单一环节下容器存储、容器网络性能测试为引，通过具体实操，帮助工程师了解熟悉容器环境下性能测试、分析的大体过程。

通过对容器云平台的技术评估选型原则、容器引擎docker的核心功能、核心技术、kubernetes的核心技术做了较为详细的阐述，并通过一定的案例穿插来达到本章节的知识点汇集。在企业中，容器云平台的核心作用都定位于大幅度的提升效率以达到软件交付的速度，同时通过提高资源的利用率来降低成本。而在实际的运用中，仅仅对容器云平台的功能使用，忽略了核心技术的场景运用，造成容器云平台的使用效果没有达到预期效果。因此，在本章节中，通过以容器云平台的需求评估为出发点，围绕docker和kubernetes的关键技术，对容器支持、场景运用、网络选型、存储选型的核心技术进行阐述，以提升容器云平台的最佳实践，同样也是对《容器云平台架构分析》章节内容的补充。

随着容器技术的出现，我们开发出的应用程序才可以真正实现开发运维一体化的愿景，因为它比传统虚拟机定义了更具标准化的打包方式及更轻量级的运行状态。当业务很多时，如果我们只在一台主机上部署就不能满足业务的高可用、负载的可扩容性等需求，这时就需要我们在多台主机上部署，因此出现了集群化、分布式等技术。那我们如何在这些主机上更高效的管理这些容器，并以某些方式暴露所部署的应用服务？这就需要用到容器编排技术了，因此从2014年开始，容器领域就诞生了以Mesos、Docker Swarm及Kubernetes为代表的容器编排系统。在过去这几年间，容器编排技术已经呈现出“三国鼎立”之态势，各有个的用户群体，各有个的活动社区，但2017年至今Kubernetes已经成为真正的领导者。一种新的技术的兴起，注定会带动围绕其出现的其他新技术的崛起，这包括了容器存储、容器网络、容器日志管理及监控告警、CI/CD（持续集成/持续交付）等相关领域的技术，从而构成了我们今天火热的容器生态圈。在容器编排技术之上，我们为了更好的让开发者使用这个编排系统，就有了容器平台的出现，典型开源代表有Rancher、Openshift、Kubesphere等，它们都包括CI/CD、灰度发布、滚动升级、自动扩缩容、租户管理、安全认证等等功能模块。每一个模块也都涌现出了很多新的技术代表，这些又构成了我们今天大势宣传的云原生技术。那这么多新技术组合在一起，当我们的容器平台或者部署在其上的业务出现问题时，我们该如何分析、定位并最后排除？这就是一个摆在云容器工作者面前的重要问题。在这个章节中我就分享一些解决问题的思路、方法，并以一个实际案例来分享如何排除一个真实场景中产生的问题，希望能起到抛砖引玉的效果，并对大家有所帮助。由于容器平台涉及的问题太过宽广，使用的技术涉及知识面也很多，本章节并不能一一例举，只能点到为止。

基于Docker的各类容器调度管理平台均设计了丰富的高可用机制，但在实际落地过程中如何更好的结合企业实际实现管理平台应用的高可用将是需要深入考虑的和研究的内容。本文将围绕Kubernetes和Mesos+Marathon这两种主流Docker容器调度框架对容器管理平台本身的高可用机制进行介绍及分析，并通过案例分析深入探讨运行于容器平台上应用的高可用实现机制。

随着云计算的兴起与发展，目前比较火热的基于容器的云平台，由于底层基础架构发生了变化，支撑的应用类型和部署上线模式发生了变化，所以在监控方面也面临许多挑战，那么对容器云平台的监控在设计、实施和后期管理方面会存在哪些“坑”，该怎么“玩”，以及它和传统的监控侧重点有什么不同呢？本章节将给你逐一分析、讲解并提供一些建议。

在本章节中，我们介绍了容器云平台目前常用两种开源组件docker和kubernetes故障排查和突发情况和处理，在docker方面，首先我们通过对docker的检查进行较为详细的阐述，主要为使用docker exec来检查容器、对docker的外部进行调试、通过其他的工具和组件进行检测。在检查部分，我们也通过一些案例来讲解，同时，在docker的常见故障小节中，我们用了案例来描述了使用docker过程中，我们遇到的常见的问题，如启动时的，运用中的一些场景。在kubernetes方面，问题排查的难度高于docker，因此针对故障问题排查的顺序做了一些编排，并对排查思路做了一定的阐述。在遇到kubernetes问题时，首要任务是找到故障排查的思路，对kubernetes集群的故障排查应该遵循从下至上排查方法：先从pod开始，然后是服务和入口，依次按顺序排查。在实际案例中，分为以pod故障排查、服务故障排查、入口故障排查、和nginx入口控制器排查四个步骤进行较为详细的描述，以提高读者快速排查问题和解决问题的能力。

本文主要介绍了在云原生时代，Kubernetes 云原生存储为运行在容器环境中的有状态应用提供了持久化存储的解决方案。有状态应用容器化是云原生时代的重要趋势，容器化可以为有状态应用提供很多优势，但同时容器化的进程还存在着一定的障碍，持久化存储即为关键障碍之一。在这种背景下，云原生存储应运而生。IOMesh 致力于专为容器化应用构建存储系统，以典型的有状态应用MySQL 为例，展示了如何通过 IOMesh 在 Kubernetes 环境中运行有状态应用。

在云原生时代下，以应用上容器云推进企业 IT 技术架构转型升级已得到广泛共识，在企业开展应用上云中，标准化一定是规模上云的基础，而知识库的目的，就是建立标准和规范，同时也是每个企业推进应用上容器云的经验宝库，可有效将容器云基础设施与开发人员进行链接，为企业架构转型提速增效。本课程主要讲解知识库建设的通用性原理，围绕知识生产到消费再到知识再生产的完整闭环阐述知识库的核心建设过程，并根据应用上容器云特点提出业务以及技术上的一些建议，希望对有计划建设上云知识库的企业提供参考。

容器云平台运维架构是基于我们容器云平台架构的基础上所设计定义的，其范围是一个基于容器云平台的PaaS平台运维架构。首先依据镜像仓库的定位和能力，隔离开发、测试和生产不同阶段，从而使相关人员的职责更加清晰，符合传统企业的IT运营模式，也通过工具的采用减少了IT人员的工作量，提升了工作效率。而在部署运维运营阶段，把应用运维、平台运维和基础设施资源运维分离，使相关人员更专注于自己擅长的工作，通过自动化流程实现衔接，从而提升效率。为了提升应用运维能力，定义实现两层服务治理架构，充分考虑容器特性和全局API设计要求，从安全性、便利性、可扩展性、稳定性等方面满足企业生产就绪要求。

一款产品从开发到上线，从操作系统到运行环境，再到应用配置。作为开发+运维之间的协作我们需要关心很多东西，这也是很多互联网公司都不得不面对的问题，特别是各种版本的迭代之后，不同版本环境的兼容，对运维人员都是考验。安装的时候，把原始环境一模一样地复制过来，开发人员利用 Docker 可以消除协作编码时“在我的机器上可正常工作”的问题。

随着移动互联网时代的大步跃进，互联网公司业务的爆炸式增长发展给传统行业带来了巨大的冲击和挑战，被迫考虑转型和调整。对于我们传统的航空行业来说，还存在传统的思维、落后的技术。一项新业务从提出需求到立项审批、公开招标、项目实施、上线、交付运维，没有一年半载下不来。而此中最为严重的问题是，系统交付时的功能可能已经偏离最初的需求，系统使用方不满意，IT人员觉得付出的劳动没有被认可，双方矛盾加剧。大力发展移动互联网业务，因此对业务需求的响应速度有了更高的要求，越来越多传统应用架构，为了适应不断变化的业务需求和难以预估的访问量而开始进行分布式改造、微服务改造，实现持续集成、持续发布、自动化测试、支持弹性伸缩、灰度发布、蓝绿部署等能力，容器云平台恰恰可以很好的支撑上述需求。容器技术是近些年来最火爆的技术方向之一，容器云能更好服务于应用，不断提升客户满意度。按照云计算的三种类型，建设PaaS(Platform as a service)平台将有助于我们实现这些目标。 目前许多公司采用了Vmware技术完成了Iaas虚拟化建设，而IaaS虚拟化层仅提供了对存储、网络、计算资源的管理，在IaaS上即使经过了深度的定制化自动改造，流程走完时也是普遍在交付时将带有应用软件及软件配置的一台虚拟机交付到申请者手中，申请者需要自己通过ip登录到机器上部署相应的应用，更不用说各应用组件之间的配合设置。而在容器平台中从代码开发集成到一个容器镜像打包了应用程序和运行环境，加上容器的配置文件，一整套流程走下来时，应用已经可以直接上线了，负载均衡，安全策略都可以具备，可以说容器云平台是Devops理论的最佳实践。 对于容器平台的建设，从初期就需要做好平台的整体规划，切莫为了容器化而容器化，还是要因地制宜，寻找平衡点逐渐落地，混合实施，了解开发运维等多方面的需求、平台相关技术的原理机制，团结开发、运维、用户等才能共同设计好一个容器平台。 本文基于对容器云平台的应用和研究，详细探讨容器云平台的规划部署和架构设计。

本章节分为两个大类，分别是常见的容器云平台的开源监控工具，包括了较为常见的Prometheus、Grafana、Elastic Stack、Sensu和Sysdig Inspect，并将Prometheus和Zabbix、Graphite、Influxdb和Opentsdb相比较，得出Prometheus的优点，无论从支撑组件和架构层面来看，具备和容器云平台结合的优势，主要体现在完善的生态、齐全的功能和扩展性。本章节中对Prometheus的安装和部署做了详细的介绍，更多的篇幅让读者了解到Prometheus如何对容器集群和Kubernetes编排集群进行监控，并列举了二者较为常见的监控点。通过本章节的学习，读者可以系统的学习到如何构建一个完整的针对容器云平台的监控系统。

在本章节中，我们分别从三个方面进行阐述容器云自动化引擎的技术选型，其中包括自动化引擎的工具选型，主要针对开源领域拥有社区资源最为丰富的三个工具，分别为puppet、ansible、saltstack。就三个工具从推荐场景、技术特性、优缺点比较三个方面进行分析和比对，在此过程中我们选择了ansible作为容器云平台的自动化引擎组件。在第二个部分主要为ansible和docker的集成，主要分为两点，第一点为ansible针对docker的模块介绍和基本案例，第二点为通过蓝绿发布的案例来阐述ansible和docker的集成带来的优点。在第三部分主要为ansible和kubernetes的集成，主要为常见的k8s模块的使用，以案例的方式来描述ansible如何管理kubernetes的资源。

Kubernetes要用于生产，其权限控制不可缺少。其实在kubernetes的演变升级过程中，对权限方面的精进是非常明确的，早在1.6版本，Kubernetes默认就启用RBAC访问控制策略，而从1.8开始，RBAC已作为稳定的功能存在了。使用原生的kubernetes RBAC仍然不失为一个不错的权限管理方式。红帽OpenShift默认也是采取K8S的RBAC方式。本文将完整的介绍Kubernetes用户角色定义和使用过程中的认证、授权、准入三大环节。