At present, more and more developers began to adopt Kubernetes management infrastructure environment, and through Kubernetes to complete the daily development, testing and production release activities, in order to effectively help developers improve the local development test efficiency in the Kubernetes scenario, Alibaba r&d efficiency cloud effect team open source for native Kubernetes a lightweight developer tool KT Connect.
1. What is KT Connect
KT Connect (Kubernetes Developer Tool) is a lightweight development test environment governance Tool for Kubernetes users. Its core is to improve the efficiency of the development link and reuse of the development test environment in the continuous delivery life cycle by establishing local to cluster and cluster to local two-way channel:
KT Connect includes a set of Cli commands for quick local and cluster tuning: Connect, Exchange, Mesh, and a centralized visual Dashboard.
- Connect: On the basis of Kubectl based on SSH protocol to build a VPN network from local to Kubernetes cluster, so that users can directly access the internal network of Kubernetes cluster such as PodIP, ClusterIP. Based on the built-in DNS Service, developers can directly access Service DNS addresses in the cluster.
- Exchange: Helps developers add local services to the cluster for tuning testing by enabling the deployment broker container to take over all traffic to a particular application in the cluster and forward it to the developer’s local port.
- Mesh: Similar to Exchange, the difference is that Mesh does not take over all traffic. Instead, a Pod instance with a specific version number is deployed after Service, and Istio traffic management rules are used to forward specific traffic to the developer.
With KT Connect, developers can get out of the traditional “develop-build-deploy” scenario and directly implement local development and local coordination, which can greatly improve development efficiency. At the same time, Mesh provides mixing capability and reduces resource investment at the infrastructure level by reusing the test environment.
2. Advantages of KT Connect
KT Connect grew out of Alibaba’s experience in testing scalable environments and was inspired by developer tools like Azure Dev Spaces and Telepresence, And the formation of a set of native Kubernetes user test environment governance and local joint adjustment solutions:
- Native Kubernetes support: compatible with any Kubernetes cluster, at the same time to support the way to run kubectl plug-in;
- Lightweight: Implemented based on Go, it mainly relies on SSHUttle for VPN network capability of CONNECT, without any third party. Users can use KT Connect in any environment where Kubectl is running properly.
- Multiple application scenarios: through integration with native Istio, support user exclusive or shared development test environment;
- Visualization: Based on the same Dashboard and visualization capabilities, users can more intuitively understand the usage of the test environment.
- Scalability: KT Connect provides detailed metadata information that allows users to quickly extend dashboards and features based on the Kubernetes API;
3. Origin of KT Connect
Over the years, the idea of continuous delivery has taken root and practices have improved, and publishing has become a one-click thing. The entire continuous delivery process becomes increasingly automated, activities such as quality and infrastructure definition move to the left, and the maximum time invested in r&d returns to the code itself.
Today, in the mode of teamwork, no matter how much change has taken place in the software development mode or architecture over the years, the biggest problem affecting the efficiency of software development is still the problem of integration.
3.1 Alibaba’s solution
In DevOps, software is constantly integrated through a continuous delivery pipeline, and the later stages are closer to production. The verification results of the integration give developers more confidence that the code will work in production:
Ideally, we would like to automate the pipeline for continuous integration validation, phase by phase environment deployment. And complete the collaboration of various roles in these links:
- “Who messed up the routine again!!”
- “Change one line of code and deploy for ten minutes…”
These are the true feelings of the R&D team after the practice of continuous delivery pipeline. We all know that local development and local coordination are the most efficient, but the continuous delivery pipeline by itself does not solve these problems. Fortunately, the group has Aone and strong middleware capabilities. The isolation ability based on middleware and the office network under the group environment are directly connected with the daily environment network. Before the integration is actually committed, developers can use a separate test environment locally to do joint testing:
In addition to the independent use of the project environment, in order to improve the daily environment of the problem, AriaOne also introduced the trunk environment mode to improve the stability of the integrated environment. As mentioned above, there are some preconditions for the efficiency of integrated joint testing within the group:
- The first is that the group can have redundant infrastructure for exclusive use by developers
- The second is the group network environment. Office network and daily environment are directly connected
- The third is a strong middleware isolation capability that allows traffic to flow as planned by the developer
3.2 KT Connect’s solution
3.2.1 Connect Connection:
Quickly establish a VPN network from the local to the cluster, and integrate the DNS resolution capability of Kubernetes cluster into the local, so that users can directly access the services in the cluster through PodIP, ClusterIP and DNS domain name:
By establishing a local to cluster channel, developers can quickly test with other services in the cluster. At the same time, due to the compatibility of Kubernetes DNS capabilities, it can make the local code as if it is directly running in the cluster.
3.2.2 Exchange:
How does the traffic in the cluster get to the developer’s local process? Exchange provides the ability to replace existing applications in a cluster by deploying the proxy container within the cluster and forwarding all requests to the proxy container directly to the local port:
Local to cluster and cluster to local access are handled through Connect and Exchange commands respectively. By combining with Kubernetes’ Namespace isolation, Kubernetes native developers can fulfill local to cluster and cluster to local tuning and integration requirements on a proprietary test environment.
3.2.3 Mesh Mixing:
Here’s another question: Do we really need an exclusive “project test environment”?
The significance of the existence of the project environment in the group is ultimately due to the unstable environment. The development integration efficiency is directly reduced. Is there a solution under Kubernetes? Speaking of which, there must be. Next, WE introduce KT Connect’s third capability: Mesh
The capabilities of Mesh and Exchange are similar in that each invocation starts a proxy container within the cluster and inherits the original application’s tags. But the biggest difference is that Exhange directly reduces the Replicas of the original application to 0, completely resulting in all the traffic to the original application in the cluster. On the premise of keeping the original application Pod unchanged, the Mesh creates a new proxy container and inherits all the labels of the original application, but adds a random version label.
At this point, the reader may be thinking that just adding a version doesn’t seem like much of a change. However, new chemical reactions can occur when the Service Mesh is used. Because the original application still exists, Mesh is deployed to the Kubernetes cluster in the form of a new version of the application. In coordination with Istio traffic rules, all normal traffic can still access the original application, and only some special marked requests are forwarded to the local. Thus, local integration can be independently completed on the basis of a set of common test environment.
3.2.4 Dashboard Visualization:
From the perspective of the client, Cli tool provides a relatively convenient way for the developer to quickly complete the joint commissioning test locally. From the perspective of test environment management, we need to know the status of the test environment, for example, how many services are transferred to the developer locally by Exchange. How many local versions of the service Mesh are there? This part is supported by a centralized Dashboard in KT Connect. We can clearly understand the container instance running under the current service and whether there is local environment access, which can better support the multi-person collaboration scenario.
4. Application scenarios of KT Connect
4.1 Local joint test
Within Ali, developers can create a separate development test environment for each change and coordinate with local programs. In Kubernetes, by assigning a separate namespace and combining connect and Exchange commands, It allows developers to conduct co-tuning tests in a proprietary development test environment.
4.2 Sharing the Development test Environment
In addition to a proprietary development test environment, the combination of Istio and connext and mesh commands enables a group of developers to perform local tuning tests simultaneously in a shared development test environment. Thus, the investment of infrastructure resources can be greatly saved.
4.3 Continuous delivery to the assembly line
Within Ali, we usually have a separate trunk environment, and every time a change is released to formal and merged into the trunk code, it triggers the deployment of the trunk environment, which means that the trunk environment is a stable environment by default. In the continuous delivery pipeline based on Kubernetes, we can also very convenient simulation of a trunk environment, and by default through the trunk environment to carry out local joint test, so as to avoid the daily environment instability can not effectively carry out the task of local joint test.
5. RoadMap
We plan to Release one version per month on average. Currently, we plan to:
Visualization and test environment management
- Provide test environment templates and baseline management to help users pull up the test environment with one click;
- A Namespace protection mechanism is provided for a cluster that contains both the test environment and the production environment, preventing clients from taking over traffic in the production environment.
- Visualization ability to enhance the overall visual topology of the cluster;
- Istio visual management. Generate traffic rules visually or automatically using Dashboard.
Performance and stability optimization
- Optimize proxy container size and startup speed to improve startup efficiency;
- Cli optimization process management ability;
- The Istio capability is enhanced on the Cli. You can define traffic forwarding rules on the Cli
6. More information
- Project address: github.com/alibaba/kt-…
- Alibaba.github. IO /kt-connect/…
- Questions and feedback: github.com/alibaba/kt-…
The author: Yi Luzhou
The original link
This article is the original content of the cloud habitat community, shall not be reproduced without permission.