云原生应用
我们正经历从单体应用转向分布式微服务架构应用的技术趋势。分布式微服务架构作为越来越多的软件开发设计模式，以领域设计模型来指导业务需求的抽象与封装。对业务的实体抽象还是边界划分，会以微服务架构作为落地点，形成微服务集群。并实施运行在云原生编排平台。
云原生应用结构fromKubernetes-Patterns
云原生应用的基石是干净整洁，业务逻辑相对单一，并与其他领域对象独立的代码实现。这一阶段保证业务质量的主要是编程基本功，以及高覆盖率的自动化测试能力。
领域设计驱动是近年微服务技术热潮下的主流设计模式，主要解决的问题是如何拆解一个复杂的业务场景需求到多个微服务单元。领域设计驱动是微服务架构的设计模式，微服务架构是基于领域设计模式的实现方式。一个微服务可以对应一个领域对象，也可以是一个领域服务。分布式微服务架构实现的云原生应用具有高可用，弹性伸缩，容忍失败以及健康自省等特点。它使得我们处理日益增长的业务需求的能力从开发编程的复杂性逐渐转移到了资源整合，操作与管理的复杂性上。微服务是单一的，运行在一个单进程中的简单应用。容器技术恰好能够提供这种隔离封装，将一个简单的微服务以Dockfile模版方式标准化，可无差别得运行在分布式集群的任意资源节点。K8S作为目前最流行的云原生平台架构，对于一组微服务的交互，持续化数据的存储，或者实施多个具有依赖关系的微服务运行，以及容量规划等问题，能够提供一套自动化的系统性解决方案。用OOP方式解读K8S
对于应用开发者，面向对象模式想必了然于胸。OOP设计了一套对一个逻辑对象的生命周期管理的方法论，类比OOP思路，笔者接下来详细介绍一些K8S核心资源对象以及应用方式。
OOPvsK8SfromKubernetes-Patterns
构建/部署保持隔离性Pod/Deployment
Image
容器镜像类比OOP的类，定义了一个模块的全部属性与功能，提供了唯一暴露在外的API调用方式以及参数集合，对应着一个独立完整的发布周期，就像容器的设计蓝图。这种静态定义方式，可以定义并初始化容器进行，使其在任意环境任意时刻行为完全一致。一个容器镜像对应着一个微服务，属于开发团队的产物。
Container
容器类比OOP的对象，是容器镜像的运行态。一个容器是一个容器镜像的运行进程，而一个容器镜像则可以在任意时刻任意环境下创建任何数量容器。
Pod
Java应用开发者都知道基于Springboot-MVC框架的Java应用部署时只需提供一个Jar包，Jar包内部源码被编译后不可再改变。Pod是云原生编排平台的资源调度部署的最小单元。Pod和容器的关系类似Java的Jar包和对象，应用开发者交付的容器镜像通过Pod在K8S集群上部署并调度，容器则是Pod的内部资源对象，K8S无法感知也无法干预。K8S设计Pod为部署调度的最小单元，是因为Pod实现了内部一组容器在存储空间，网络空间及进程空间可共享该Pod资源，类似一个虚拟机上同时运行多个进程。容器间通信类似单节点进程间通信。Pod的设计，就是要让它里面的容器尽可能多地共享LinuxNamespace，仅保留必要的隔离和限制能力。Pod类似OOP的Module，即逻辑紧密的对象集合通常属于一个独立模块。Pod的定义示例如下：apiVersion:v1kind:Podmetadata:name:index-helm-c-lgww5namespace:bss-devspec:containers:-