共计 3453 个字符，预计需要花费 9 分钟才能阅读完成。
本篇内容介绍了“Demo 怎么部署”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
闲淡
Kubernates 是建立在扩展性的具备二次开发的功能层次丰富的体系化系统
首先其最核心的功能是管理容器集群，能管理容器化的集群（包括存储，计算），当然这个是建立在对容器运行时(CRI)，网络接口(CNI), 存储服务接口（CSI/FV）的基础上；
其次是面向应用 (包括无状态 / 有状态, 批处理 / 服务型应用) 的部署和路由能力，特别是基于微服务架构的应用管理，具备了其服务定义和服务发现，以及基于 configmap 的统一配置能力；
在基础资源（主要是抽象底层 IaaS 的资源）和应用层的抽象模型之上是治理层，包含弹性扩容，命名空间 / 租户，等。当然，基于其原子内核的基础能力，在 Kubernetes 的核心之上搭建统一的日志中心和全方位监控等服务是水到渠成的，CNCF 更是有其认定推荐。
来张
Kubernetes Architecture
的一张图解释下上述描述。在 2018 年 Kubernetes 往事实的 paas 底座的标配迈出质的一步，有人说原因在于基于扩展的二次开发能力，有人说在于其声明式编程和背靠 Google 和 Redhat 的强大社区运作，我觉得回归本质是在于下图中的__Layered 架构和其问题域的领域建模抽象__。
以微服务架构视角，Kubernetes 在一定意义上是微服务框架（这时较叫微服务平台或 toolkit 集更合适），支持微服务的服务发现 / 注册的基本能力。借用如下图做一个简单描述。
话题再展开一下，微服务领域涉及众多问题，大概可以用下图说明。
kubernetes 解决得只是少部分，而像动态路由，稳定性控制（断路器，隔水舱等），分布式服务追踪等是个空白，这也就是 servicemesh 要解决的，是在 CNCF 的 Trail
Map 占有重要一席；当然 Dubbo 是基本具备完备的微服务，也就是使得其集成到 k8s 体系下具有相当的意义。Dubbo 在 serviemesh 中基于 sidecar 的方案是解决跨语言诉求的通用 servicemesh 方案，需要新开一个话题来展开说；而引用 serviemsh 的
：
A
service mesh is a dedicated infrastructure layer for handling
service-to-service communication. It’s responsible for the reliable
delivery of requests through the complex topology of services that
comprise a modern, cloud native application.
首先服务网格是一个云原生环境下基础设施层，功能在于处理服务间通信，职责是负责实现请求的可靠传递，被使得被监控跟踪，被治理，最终使得微服务架构被赋予高可控的稳定性和快速的问题定位排查能力。
可以得出现有 Dubbo 集成云原生基础设施 kubernetes 的基础能力而并解决微服务相关核心问题也算是一种狭义上的 servicemesh 方案，只是是 Java 领域的罢了；当玩笑理解也行，哈哈。
思路 / 方案
kubernetes 是天然可作为微服务的地址注册中心，类似于 zookeeper，
阿里巴巴内部用到的 VIPserver，Configserver。
具体来说，kubernetes 中的 Pod 是对于应用的运行实例，Pod 的被调度部署 / 启停都会调用 API-Server 的服务来保持其状态到 ETCD；kubernetes 中的 service 是对应微服务的概念，定义如下
A Kubernetes Service is an abstraction layer which
defines a logical set of Pods and enables external traffic exposure,
load balancing and service discovery for those Pods.
概括来说 kubernetes service 具有如下特点
每个 Service 都有一个唯一的名字，及对应 IP。IP 是 kubernetes 自动分配的，名字是开发者自己定义的。
Service 的 IP 有几种表现形式，分别是 ClusterIP，NodePort,LoadBalance,Ingress。ClusterIP 主要用于集群内通信；NodePort，Ingress，LoadBalance 用于暴露服务给集群外的访问入口。
乍一看，kubernetes 的 service 都是唯一的 IP，在原有的 Dubbo/HSF 固定思维下：Dubbo/HSF 的 service 是有整个服务集群的 IP 聚合而成，貌似是有本质区别的，细想下来差别不大，因为 kubernetes 下的唯一 IP 只是一个 VIP，背后挂在了多个 endpoint，那才是事实上的处理节点。
此处只讨论集群内的 Dubbo 服务在同一个 kubernetes 集群内访问；至于 kubernetes 外的 consumer 访问 kubernetes 内的 provider，涉及到网络地址空间的问题，一般需要 GateWay/loadbalance 来做映射转换，不展开讨论。针对 kubernetes 内有两种方案可选：
DNS：默认 kubernetes 的 service 是靠 DNS 插件(最新版推荐是 coreDNS)，Dubbo 上有个
proposal
是关于这个的。我的理解是 static resolution 的机制是最简单最需要支持的一种 service discovery 机制，具体也可以参考 Envoy 在此的
，由于 HSF/Dubbo 一直突出其软负载的地址发现能力，反而忽略 Static 的策略。同时蚂蚁的 SOFA 一直是支持此种策略，那一个 SOFA 工程的工程片段做一个解释。这样做有两个好处，1）当软负载中心 crash 不可用造成无法获取地址列表时，有一定的机制 Failover 到此策略来处理一定的请求。
2）在 LDC/ 单元化下，蚂蚁的负载中心集群是机房 / 区域内收敛部署的，首先保证软负载中心的 LDC 化了进而稳定可控，当单元需要请求中心时，此 VIP 的地址发现就排上用场了。
API：DNS 是依靠 DNS 插件进行的，相当于额外的运维开销，所以考虑直接通过 kubernetes 的 client 来获取 endpoint。事实上，通过访问 kubernetes 的 API
server 接口是可以直接获取某个 servie 背后的 endpoint 列表，同时可以监听其地址列表的变化。从而实现 Dubbo/HSF 所推荐的软负载发现策略。具体可以参考代码：
以上两种思路都需要考虑以下两点
kubernetes 和 Dubbo 对于 service 的名字是映射一致的。Dubbo 的服务是由 serviename，group，version 三个来确定其唯一性，而且 servicename 一般其服务接口的包名称，比较长。需要映射 kubernetes 的 servie 名与 dubbo 的服务名。要么是像 SOFA 那样增加一个属性来进行定义，这个是改造大点，但最合理；要么是通过固定规则来引用部署的环境变量，可用于快速验证。
端口问题。默认 Pod 与 Pod 的网络互通算是解决了。需要验证。
Demo 验证
下面通过阿里云的容器镜像服务和 EDAS 中的 kubernetes 服务来做一次 Demo 部署。
访问阿里云 -》容器镜像服务，创建镜像仓库并绑定 github 代码库。如下图
点击管理进行创建好的仓库，通过镜像服务下的构建功能，把 demo 构建成 image，并发布到指定仓库。如下图。
切换到企业级分布式应用服务（EDAS）产品，在资源管理 –》集群 下创建 kubernetes 集群并绑定 ECS，如下图.
应用管理 -》创建应用，类型为 kubernetes 应用 并且指定在容器镜像服务中的镜像。如下图。
创建完成后，进行应用部署。如下图
补充
应用名不能有大写字母，是要小写，否则有部署失败的问题。
在创建应用时，选中镜像后，下一步的按钮无法点击，需要点击选择继续。
EDAS 有两套独立的 kubernetes 服务，一套是基于阿里云的容器服务，一套是 Lark 自己搞的。本人体验的是后者。
Docker 与 IDE 集成的开发联调，需要考虑集成 IDEA 的相关插件。
“Demo 怎么部署”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
