Shulou(Shulou.com)06/02 Report--

Next Saturday, Shenzhen, the long-lost offline technology salon will meet you!

There are Rancher Labs R & D manager demo just released Istio, Windows container, cluster template and other functions and use in Rancher 2.3, as well as K3s offline workshop for the first time, with senior Rancher Labs architect taking you to play K3s! There is also the head of operation and maintenance of Great Wall Securities to share the transformation of traditional financial IT under the wave of digitization.

Visit the link to learn more and sign up!

The maturity of native cloud architectures and technologies such as containers and Kubernetes promotes the rapid growth and widespread adoption of service grid architecture. Although the cloud native environment can bring a series of benefits to enterprises, its complexity also poses major challenges for those responsible for developing and maintaining such systems, such as software developers, network operations and maintenance personnel, infrastructure engineers, CIO, CTO and so on.

Service grid framework can integrate consistent service and network management capabilities for applications across different cloud native environments, and it also greatly speeds up the process of DevOps practice. Because of this, service grid has developed rapidly in recent years. The acceleration of cloud native popularity requires engineering teams with cloud native applications to be familiar with service grid capabilities to determine whether the technology can provide value to enterprises in the future.

What is a service grid?

Service grids can connect, protect, control, and monitor services on the orchestration platform. The term "service grid" itself applies to a set of lapped network connections between services in distributed applications, as well as to a range of tools for managing that set of connected services. If you have two microservices that interact over a network connection, that means you have a service grid. The following figure is a very simple example of a grid and two services:

More likely, as the number of microservices in the environment continues to grow, your service grid will look like the following figure:

As cloud environments expand to hybrid and multi-cloud deployments, developers will use microservices to accelerate development and ensure portability across multiple containers and distributed cloud resources. As the complexity of the microservices ecosystem grows, we need to manage it efficiently and intelligently, and learn more about how microservices interact and protect communication between microservices.

What is Istio?

If you've heard about the service grid, you must have heard about Istio by the way. Istio is an open source service grid that can be deployed on existing cloud native applications. It also has platform-like functionality-it can be integrated into logging platforms, telemetry, or policy systems. Policy integration enables Istio to act as a security tool in creating a unified way to protect, connect, and monitor micro-services in a given environment. When referring generally to "Istio service grid", it usually refers to a series of tools in Istio, while "an Istio service grid" in particular indicates the specified application cluster managed by the Istio installation. Many of Istio's CRD allow programmatic configuration (through the use of Kubernetes API) of the behavior of applications at the network layer, where applications are interdependent sets of microservices. To some extent, Istio can be called synonymous with service grid in today's cloud native stack because it is the most feature-rich and standardized.

Do I need a service grid?

Although the adoption rate of the service grid is likely to continue to grow rapidly, especially as functional settings and Istio-like management tools are further improved, not every cloud native environment requires a service grid. So how do you know if a service is suitable for your business or environment? If you need a solution to one or more of the requirements or problems described below, you should consider deploying a service grid:

You encounter performance problems in applications based on distributed microservices

You need to collect and deliver consistent request and connection metrics for all microservices

You want to directly default online encryption settings without directly managing TLS certificates

You need a finer-grained solution for service-to-service control than the Kubernetes network strategy provides.

You want to use Canary release and application API multi-version support for automatic release

You want to add user authentication and authorization information without modifying the application

On the other hand, if you don't need a service grid in your stack, you need to make some tradeoffs. Considering the complexity of these environments, deploying a service grid (including Istio) requires a lot of migration work and operation and maintenance costs. If your number of microservice deployments does not grow, or if there are other solutions that can meet your internal HTTP request routing needs, or if you already have a manageable and efficient solution to address the above key requirements, then service grid is really not the best choice for you at the moment.

But if the service grid continues to be widely adopted, the functional ecosystem developed to support it will continue to expand. This growth will improve manageability and functionality so that in the future DevOps teams can more easily access the more powerful service grid tools without having to worry about the thorny problems or high costs of deploying new infrastructure layers to the cloud native stack.

How Istio works

The Istio component is divided into two parts-the control plane and the data plane. The control plane is the service that manages the configuration and monitors the data plane. The data plane consists of intelligent agents (proxy) as sidecar in the application pod, which is the smallest deployable object in the Kubernetes object model. These Istio proxy help control and monitor network connections between microservices. Routing and policy rules are received from the control plane, and then the data plane reports back to the connection to handle telemetry.

Configure the Istio service grid by creating Kubernetes resources. In addition, there are many Kubernetes CRD that can be mapped to various functions of Istio. Next, we'll talk more about the role of control and data planes, but before we do that, let's learn about the potential capabilities of Istio and its shortcomings.

Potential and deficiency

Istio provides a range of features for handling and controlling network connections through its grid of dynamically configurable agents. But these features are heavily configured and have a steep learning curve. And sometimes there are some common problems when migrating existing applications to Istio architectures, even though these architectures are native Kubernetes microservices.

In addition, Istio lacks understanding of how to convert user-provided configurations into Envoy routes. Envoy is a high-performance proxy developed as an intermediary for inbound and outbound traffic of services in a service grid. It is created by developers from Lyft, a shared travel service company, and can be used to transform from a single architecture to a service grid architecture. Other issues in use include the learning curve required for deployment and service resource configuration requirements, interrupting Kubernetes readiness and liveness probes when opening mTLS, and services using Kubernetes services without ClusterIP or bypassing the Kubernetes service discovery process.

The advantage of Istio is that it allows you to easily add functions such as load balancing, authentication, monitoring, and so on, to microservices without modifying the source code of microservices. And at present, it is developing iterations rapidly, releasing new versions frequently, and actively soliciting user feedback. Although Envoy still has many limitations at present, as Istio continues to develop, it will actively develop and improve its own functions.

Configure the control plane

In a Kubernetes cluster, a typical Istio deployment should include the following services:

Pilot, which collects the traffic management specification configuration in the Istio network custom resources and delivers the configuration to istio-proxy sidecar.

Mixer, which processes the telemetry of the request metrics generated by proxy sidecar, sends it to the configured backend, and enforces the authorization policy. If policy checking is enabled (off by default in Istio 1.1), proxy sidecar will connect to Mixer to confirm that the connection is allowed. However, this approach slightly increases network latency.

Citadel, Istio's public key infrastructure (PKI) service, which generates, rotates, and revokes client-side TLS certificates for authentication.

Galley, the Kubernetes controller for most Istio CRD, allows users to change custom resources and assign content to other Istio services.

Data plane

The data plane is supported by an Envoy service agent, which is built using Istio extensions. Proxy intercepts incoming traffic to the pod service port and by default blocks all outgoing TCP traffic from other pod containers. In most cases, proxy sidecar can run in pod without changing the application code, with minor changes to the application's Kubernetes deployment and service resource specifications. The configuration of the Proxy sidecar is dynamically managed by the services in the Istio control panel.

Eventually, at some point you may need to deploy a service grid to ensure that your cloud native environment is fully operational and fully protected. Therefore, familiarity with the basics of the service grid will only help you make accurate decisions about when and how the service grid should be deployed. If you are planning to expand on Kubernetes and other container platforms, then by understanding the design and functionality of Istio and how it reduces the inherent complexity of containerized microservices and cloud native environments, you can know that Istio is a powerful and rapidly improving solution and is actively enhancing scalability, security, and ease of management.

If enterprises continue to adopt cloud-native and distributed architectures, the service grid capabilities of Istio and the network control of the underlying infrastructure and the security practices of Kubernetes will greatly relieve the pressure on the DevOps team to scale and manage the application infrastructure.

In Rancher version 2.3 of GA on October 9th, Istio was officially integrated, greatly simplifying the installation and configuration of Istio. You only need to use the tools menu in UI to start Istio. Rancher now has built-in support for:

Kiali dashboard for flow and telemetry visualization

Jaeger for tracking

Prometheus and Grafana for monitoring and observability

If you want to know more about the new features of Rancher 2.3, you are welcome to join us in our technology salon, coordinates Shenzhen, next Saturday. At that time, there will be an on-site introduction by the R & D manager of Rancher Labs Greater China and the new features of demo Rancher 2.3. click here to sign up!

Welcome to add a small assistant (× ×: × ×) to join the official technical group to learn more about Kubernetes usage strategies.

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.