You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by li...@apache.org on 2018/08/30 04:08:16 UTC
[incubator-dubbo-website] branch asf-site updated: Merge pull
request #115, english version for blog dubbo-k8s.
This is an automated email from the ASF dual-hosted git repository.
liujun pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/incubator-dubbo-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 70b2e06 Merge pull request #115, english version for blog dubbo-k8s.
70b2e06 is described below
commit 70b2e06f6dd5c69b8adb58a039b1a0ce861e0a56
Author: IaMJamesHuang <38...@users.noreply.github.com>
AuthorDate: Thu Aug 30 12:08:14 2018 +0800
Merge pull request #115, english version for blog dubbo-k8s.
---
blog/en-us/dubbo-k8s.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++--
blog/zh-cn/dubbo-k8s.md | 39 ++++++++++++++--------------
2 files changed, 84 insertions(+), 22 deletions(-)
diff --git a/blog/en-us/dubbo-k8s.md b/blog/en-us/dubbo-k8s.md
index 7da6bdc..ecd151a 100644
--- a/blog/en-us/dubbo-k8s.md
+++ b/blog/en-us/dubbo-k8s.md
@@ -1,2 +1,65 @@
-Part 1
-Part 2
+At first sight, the service of kubernetes has its own IP, while under the original fixed mindset: Dubbo/HSF service is aggregated by the IP of the entire service cluster, that means, kubernetes and Dubbo/HSF look like something different in natural, but when carefully thinking, the difference becomes insignificant. Because the only IP under kubernetes is just a Virtural IP--VIP, behind the vip are multiple endpoints, which is the factual processing node.
+
+Here we only discuss the situation that the Dubbo service in the cluster is accessed in the same kubernetes cluster, As for the provider outside kubernetes to access the provider in kubernetes, since it involves the problem of network address space, and it usually requires GateWay/loadbalance for mapping conversion, which there not detail discussion for this case. Besides, there are two options available for kubernetes:
+
+1. DNS: The default kubernetes service is based on the DNS plugin (The latest version of the recommendation is coreDNS), one proposal on Dubbo is about this. since HSF/Dubbo has always highlighted its soft-load address discovery capability, it ignores Static's strategy insteadily, my understanding is that as a service discovery mechanism, the static resolution mechanism is one of the simplest and most needed to support mechanism, you can also refer to Envoy's point of views. While at th [...]
+
+ 
+
+2. API：DNS relies on the DNS plugin, which will generate additional operation, so consider directly obtaining the endpoint through the client of kubernetes. In fact, by accessing the API server interface of kubernetes, you can directly obtain the list of endpoints behind a certain servie, and can also monitor the changes in its address list. Thereby implementing the soft load discovery strategy recommended by Dubbo/HSF. Refer to the code for details:
+
+The above two thoughts need to consider the following two points:
+
+1. Kubernetes and Dubbo are consistent with the mapping name of service. Dubbo's service is determined by serviename, group, version to determine its uniqueness, and servicename generally has a longer package name for its service interface. Need to map the servie name of kubernetes and the service name of dubbo. Either add a property like SOFA to define it. This is a big change, but it is most reasonable. Or it is a fixed rule to reference the deployed environment variables, which can be [...]
+2. Port problem:The default Pod and Pod network interoperability is solved, need to be validated.
+
+## Demo Verification
+
+The following is a demo deployment through kubernetes service in Alibaba Cloud's Container Registry and EDAS. Visit Alibaba Cloud -》Container Registry.
+
+1. Create repo and bind the github codebase. As shown below.
+
+
+
+
+
+
+2. Click Manage enter the repository details page. Click Build in images service panel, construct the demo into image and publish it to the specified repository. As shown below.
+
+ 
+
+
+
+3. Switch to Enterprise Distributed Application Services (EDAS) products panel, visit Resource Management -》Clusters. Create kubernetes cluster and bind ECS. As shown below.
+
+ 
+
+
+
+4. Application Management - 》Create application, type kubernetes application and specify the image in the container registry . As shown below.
+
+ 
+
+
+
+ 
+
+
+
+5. After creation , then deploy applications. As shown below.
+
+ 
+
+- The supplementary application name cannot have uppercase letters, all lowercase, otherwise there is a problem of deployment failure.
+
+- When creating an app, after selecting the image, the next button cannot be clicked and you need to click Choose to continue.
+
+- EDAS has two independent kubernetes services, one based on Alibaba Cloud's container service, and one set by Lark. I experience the latter.
+
+- The development joint of Docker and IDE integration, you need to consider the relevant plug-ins for integrating IDEA.
+
+- There is always an error in deployment, maybe there is a problem with the kubernetes service. Need further investigation.
+
+{"kind":"Pod","namespace":"lzumwsrddf831iwarhehd14zh2-default","name":"dubbo-k8s-demo-610694273-jq238","uid":"12892e67-8bc8-11e8-b96a-00163e02c37b","apiVersion":"v1","resourceVersion":"850282769"},"reason":"FailedSync","message":"Error syncing pod","
+
+
diff --git a/blog/zh-cn/dubbo-k8s.md b/blog/zh-cn/dubbo-k8s.md
index 3aa4e61..aadd0df 100644
--- a/blog/zh-cn/dubbo-k8s.md
+++ b/blog/zh-cn/dubbo-k8s.md
@@ -43,51 +43,50 @@ kubernetes是天然可作为微服务的地址注册中心，类似于zookeeper
- 每个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内有两种方案可选：
+乍一看，kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思维下：Dubbo/HSF的service是由整个服务集群的IP聚合而成，貌似是有本质区别的，细想下来差别不大，因为kubernetes下的唯一IP只是一个VIP，背后挂在了多个endpoint，那才是事实上的处理节点。此处只讨论集群内的Dubbo服务在同一个kubernetes集群内访问；至于kubernetes外的consumer访问kubernetes内的provider，涉及到网络地址空间的问题，一般需要GateWay/loadbalance来做映射转换，不展开讨论。针对kubernetes内有两种方案可选： ：
-1. DNS： 默认kubernetes的service是靠DNS插件(最新版推荐是coreDNS)， Dubbo上有个proposal是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service discovery机制，具体也可以参考Envoy在此的观点，由于HSF/Dubbo一直突出其软负载的地址发现能力，反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略，那一个SOFA工程的工程片段做一个解释。这样做有两个好处，1）当软负载中心crash不可用造成无法获取地址列表时，有一定的机制Failover到此策略来处理一定的请求。 2）在LDC/单元化下，蚂蚁的负载中心集群是机房/区域内收敛部署的，首先保证软负载中心的LDC化了进而稳定可控，当单元需要请求中心时，此VIP的地址发现就排上用场了。
+1. DNS： 默认kubernetes的service是靠DNS插件(最新版推荐是coreDNS)， Dubbo上有个proposal是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service discovery机制，具体也可以参考Envoy在此的观点，由于HSF/Dubbo一直突出其软负载的地址发现能力，反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略，那一个SOFA工程的工程片段做一个解释。这样做有两个好处，1）当软负载中心crash不可用造成无法获取地址列表时，有一定的机制Failover到此策略来处理一定的请求。 2）在LDC/单元化下，蚂蚁的负载中心集群是机房/区域内收敛部署的，首先保证软负载中心的LDC化了进而稳定可控，当单元需要请求中心时，此VIP的地址发现就排上用场了。
-
+
2. API：DNS是依靠DNS插件进行的，相当于额外的运维开销，所以考虑直接通过kubernetes的client来获取endpoint。事实上，通过访问kubernetes的API server接口是可以直接获取某个servie背后的endpoint列表，同时可以监听其地址列表的变化。从而实现Dubbo/HSF所推荐的软负载发现策略。具体可以参考代码：
-以上两种思路都需要考虑以下两点
+以上两种思路都需要考虑以下两点:
+
+1. kubernetes和Dubbo对于service的名字是映射一致的。Dubbo的服务是由serviename，group，version三个来确定其唯一性，而且servicename一般其服务接口的包名称，比较长。需要映射kubernetes的servie名与dubbo的服务名。要么是像SOFA那样增加一个属性来进行定义，这是个大的改动，但最合理；要么是通过固定规则来引用部署的环境变量，可用于快速验证。
+2. 端口问题：默认Pod与Pod的网络互通算是解决了，需要验证。
+
-1. kubernetes和Dubbo对于service的名字是映射一致的。Dubbo的服务是由serviename，group，version三个来确定其唯一性，而且servicename一般其服务接口的包名称，比较长。需要映射kubernetes的servie名与dubbo的服务名。要么是像SOFA那样增加一个属性来进行定义，这个是改造大点，但最合理；要么是通过固定规则来引用部署的环境变量，可用于快速验证。
-2. 端口问题。默认Pod与Pod的网络互通算是解决了。需要验证。
## Demo验证
下面通过阿里云的容器镜像服务和EDAS中的kubernetes服务来做一次Demo部署。访问阿里云-》容器镜像服务。
-1. 创建镜像仓库并绑定github代码库。如下图
+1. 创建镜像仓库并绑定github代码库。如下图
-
+
-2. 点击管理进行创建好的仓库，通过镜像服务下的构建功能，把demo构建成image，并发布到指定仓库。如下图。
+2. 点击管理***进行创建好的仓库***，通过镜像服务下的构建功能，把demo构建成image，并发布到指定仓库。如下图。
-
+
3. 切换到企业级分布式应用服务（EDAS）产品，在资源管理 - 》集群 下创建kubernetes集群并绑定ECS，如下图.
-
+
-4. 应用管理 -》创建应用，类型为kubernetes应用 并且指定在容器镜像服务中的镜像。如下图。
+4. 应用管理 -》创建应用，***类型为kubernetes应用*** 并且指定在容器镜像服务中的镜像。如下图。
-
+
-
+
5. 创建完成后，进行应用部署。如下图
-
-
-
+
-- 补充应用名不能有大写字母，是要小写，否则有部署失败的问题。
+- 补充应用名不能有大写字母，全部小写，否则有部署失败的问题。
-- 在创建应用时，选中镜像后，下一步的按钮无法点击，需要点击选择继续。
+- 在创建应用时，选中镜像后，下一步的按钮无法点击，需要点击选择来继续。
- EDAS有两套独立的kubernetes服务，一套是基于阿里云的容器服务，一套是Lark自己搞的。本人体验的是后者。