Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "how to deploy Demo". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Idle and dull

Kubernates is a systematic system with rich functional layers with secondary development based on expansibility.

First of all, its core function is to manage container clusters, which can manage containerized clusters (including storage and computing). Of course, this is based on container runtime (CRI), network interface (CNI), and storage service interface (CSI/FV).

The second is application-oriented deployment and routing capabilities (including stateless / stateful, batch / service-oriented applications), especially application management based on micro-service architecture, with its service definition and service discovery, as well as unified configuration based on configmap.

Above the basic resources (mainly abstracting the resources of the underlying IaaS) and the abstract model of the application layer is the governance layer, including elastic expansion, namespaces / tenants, and so on. Of course, based on the basic capabilities of its atomic kernel, it is natural to build a unified log center and omni-directional monitoring services on top of the core of Kubernetes, and CNCF has its own recommendations.

Take a picture of Kubernetes Architecture to explain the above description. In 2018, Kubernetes took a qualitative step towards the standard configuration of the de facto paas base, some people say that the reason lies in the extended secondary development capability, and some say it lies in its declarative programming and strong community operation backed by Google and Redhat. I think the essence of regression lies in the _ _ Layered architecture and the domain modeling abstraction of its problem domain in the following figure.

Cdn.yuque.com/lark/0/2018/png/1217/1531965342241-d95bf6b8-037e-4923-8ce1-245d7872b0e7.png ">

From the perspective of micro-service architecture, Kubernetes is a micro-service framework in a sense (it is more suitable than micro-service platform or toolkit set), which supports the basic ability of service discovery / registration of micro-services. Borrow the following picture to make a brief description.

To further expand the topic, there are many issues in the field of microservices, which can probably be illustrated by the following figure.

Kubernetes solves only a few parts, but dynamic routing, stability control (circuit breakers, water compartments, etc.), distributed service tracking and so on are blank, which is what servicemesh wants to solve, which occupies an important seat in CNCF's Trail Map; of course, Dubbo basically has complete micro-services, that is, it is of great significance to integrate it into K8s system. Dubbo's sidecar-based solution in serviemesh is a general servicemesh solution to cross-language demands, which requires a new topic to expand, while quoting the original definition of 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.

First of all, the service grid is an infrastructure layer in the cloud native environment, the function is to handle the communication between services, the responsibility is to realize the reliable delivery of requests, to be monitored and tracked, and to be governed. Finally, the micro-service architecture is endowed with high controllable stability and fast problem location and troubleshooting capabilities.

It can be concluded that the existing Dubbo integrates the basic capabilities of kubernetes, the native cloud infrastructure, and solving the core problems related to micro-services can also be regarded as a narrow servicemesh solution, but only in the field of Java.

Ideas / plans

Kubernetes is a natural address registry that can be used as a micro-service, similar to VIPserver,Configserver used internally by zookeeper and Alibaba. Specifically, Pod in kubernetes is the running instance of the application, and the scheduled deployment / start and stop of Pod will call API-Server 's service to maintain its state to service in ETCD;kubernetes is the concept of corresponding micro-service, defined as follows

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.

Generally speaking, kubernetes service has the following characteristics

Each Service has a unique name and a corresponding IP. IP is automatically assigned by kubernetes, and the name is defined by the developer.

The IP of Service has several forms, which are ClusterIP,NodePort,LoadBalance,Ingress. ClusterIP is mainly used for intra-cluster communication; NodePort,Ingress,LoadBalance is used to expose services to access entrances outside the cluster.

At first glance, the service of kubernetes is the only IP. Under the original Dubbo/HSF fixed mindset: the service of Dubbo/HSF is aggregated by the IP of the entire service cluster, which seems to be essentially different. If you think about it, there is not much difference, because the only IP under kubernetes is only a VIP, and multiple endpoint are hung behind it. That is the actual processing node.

Only the Dubbo services in the cluster are accessed within the same kubernetes cluster. As for the access of the consumer outside the kubernetes to the provider in the kubernetes, it involves the network address space and generally requires GateWay/loadbalance to do the mapping translation without discussing it. There are two options for kubernetes:

DNS: the default service for kubernetes is the DNS plug-in (coreDNS is recommended in the latest version), and there is a proposal on Dubbo about this. My understanding is that the mechanism of static resolution is the simplest service discovery mechanism that needs to be supported. You can also refer to the point of view of Envoy here. Because HSF/Dubbo has always highlighted its address discovery ability of soft load, it ignores the strategy of Static. At the same time, Ant's SOFA has always supported this strategy, and the engineering fragment of the SOFA project gives an explanation. This has two advantages: 1) when the soft load center crash is unavailable and the address list cannot be obtained, there is a mechanism for Failover to handle certain requests. 2) under the unitization of LDC/, the load center cluster of ants is convergent and deployed in the computer room / region. First of all, the LDC of the soft load center is ensured and then stable and controllable. When the unit needs to request the center, the address discovery of this VIP will be useful.

API:DNS relies on the DNS plug-in, which is equivalent to additional operation and maintenance overhead, so consider getting endpoint directly through kubernetes's client. In fact, by accessing the API server interface of kubernetes, you can directly get the endpoint list behind a servie and listen for changes in its address list. Thus the soft load discovery strategy recommended by Dubbo/HSF is realized. For more information, please see the code:

Both of the above ideas need to consider the following two points

Kubernetes and Dubbo map the same name for service. The uniqueness of Dubbo services is determined by three serviename,group,version, and servicename generally has a longer package name for its service interface. You need to map the servie name of kubernetes to the service name of dubbo. Either it is defined by adding an attribute like SOFA, which is larger, but most reasonable, or the deployed environment variables are referenced by fixed rules, which can be used for quick validation.

The problem follows the port. The network interworking between Pod and Pod by default is solved. Verification is required.

Demo verification

Let's make a Demo deployment through Aliyun's container image service and kubernetes service in EDAS.

Visit Aliyun-"Container Image Service, create an image repository and bind the github code base. The figure below is as follows

Click manage to create the repository, build the demo into image through the build function under the image service, and publish it to the specified repository. As shown in the following picture.

Switch to the enterprise distributed application service (EDAS) product, create a kubernetes cluster under Resource Management-"Cluster, and bind ECS, as shown below.

Application Management-"create an application with the type kubernetes application and specify the image in the container image service." As shown in the following picture.

After the creation is completed, deploy the application. The figure below is as follows

Supplement

The application name cannot have uppercase letters, but should be lowercase, otherwise there will be deployment failure.

When creating an application, after the image is selected, the button for the next step cannot be clicked. You need to click to select to continue.

EDAS has two separate kubernetes services, one is based on Aliyun's container service, and the other is created by Lark itself. I experienced the latter.

For the joint development of Docker and IDE integration, you need to consider the relevant plug-ins for integrating IDEA.

That's all for "how to deploy Demo". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.