We are pleased to present a preview (NSM), a connected lightweight service mesh that uses an NGINX Plus-based data plane to manage container traffic in Kubernetes environments.
NSM is free . We hope that you will try it for dev and test environments - and we are waiting for your feedback .
The implementation of the microservices methodology is fraught with difficulties with the growth of the scale of supply, as well as their complication. Communication between services becomes more complex, debugging problems become more difficult, more and more services require more resources to manage.
NSM solves these problems by providing you with:
- Securitywhich is more important now than ever. A data breach can cost a company millions of dollars annually in lost revenue and reputation. NSM encrypts all connections using mTLS, so there is simply no sensitive data that hackers can steal over the network. Access control allows you to set policies for how services communicate with other services.
- traffic management. When shipping a new version of an application, you might want to start by restricting its incoming traffic in case of an error. With NSM Intelligent Container Traffic Management, you can set a traffic restriction policy for new services that will increase traffic over time. Other features, such as rate limiting and circuit breakers, give you complete control over the traffic flow of all your services.
- Visualization. Managing thousands of services can be a debugging and visualization nightmare. NSM helps to deal with this situation with the built-in Grafana dashboard, which displays all the features available in NGINX Plus. And also the implemented Open Tracing allows you to monitor transactions in detail.
- Hybrid deliveries, if your company, like most others, does not use an infrastructure running entirely on Kubernetes. NSM ensures that old applications are not left unattended. With the help of the embedded NGINX Kubernetes Ingress Controller, old services will be able to communicate with mesh services, and vice versa.
NSM also secures applications in zero-trust environments by transparently encrypting and authenticating container traffic. It also provides transaction visibility and analysis to help you quickly and accurately launch deployments and troubleshoot issues. It also provides fine-grained traffic control, allowing DevOps teams to deploy and optimize parts of applications while allowing developers to build and easily connect their distributed applications.
How is NGINX Service Mesh arranged?
NSM consists of a unified data plane for horizontal (service-to-service) traffic and an embedded NGINX Plus Ingress Controller for vertical traffic, managed by a single control plane.
Control plane is specially designed and optimized for NGINX Plus data plane, defines traffic control rules distributed across NGINX Plus sidecars.
In NSM sidecars, proxies are set for each service in the mesh. They interact with the following open source solutions:
- Grafana, Prometheus parameters visualization, built-in NSM panel helps you at work;
- Kubernetes Ingress Controllers, to manage incoming and outgoing traffic in the mesh;
- SPIRE, CA for managing, distributing and renewing certificates in the mesh;
- NATS, a scalable system for sending messages, such as route updates, from control plane to sidecars;
- Open Tracing, distributed debugging (supported by Zipkin and Jaeger);
- Prometheus, collection and storage of characteristics from NGINX Plus sidecars, such as number of requests, connections, and SSL handshakes.
Features and Components
NGINX Plus as a data plane covers sidecar proxy (horizontal traffic) and Ingress controller (vertical), intercepting and managing container traffic between services.
Features include:
- Mutual TLS Authentication (mTLS);
- Load balancing;
- Fault tolerance;
- Speed ββlimit;
- circuit breaking;
- Blue-green and canary deployments;
- Access control.
Starting NGINX Service Mesh
To run NSM you need:
- access to the Kubernetes environment. NGINX Service Mesh is supported on many Kubernetes platforms, including Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere, and regular Kubernetes clusters deployed on hardware servers;
- Tool
kubectlinstalled on the machine where NSM will be installed from; - Access to NGINX Service Mesh release packages. The package contains the NSM images needed to upload to a private registry for containers available on the Kubernetes cluster. The package also contains
nginx-meshctlneeded to deploy NSM.
To deploy NSM with default settings, run the following command. During deployment, you will see messages that the components were successfully installed, and finally a message that NSM is running in a separate namespace (you must first and put in the registry, approx. translator):
$ DOCKER_REGISTRY=your-Docker-registry ; MESH_VER=0.6.0 ;
./nginx-meshctl deploy
--nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}"
--nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}"
--nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}"
--nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"
Created namespace "nginx-mesh".
Created SpiffeID CRD.
Waiting for Spire pods to be running...done.
Deployed Spire.
Deployed NATS server.
Created traffic policy CRDs.
Deployed Mesh API.
Deployed Metrics API Server.
Deployed Prometheus Server nginx-mesh/prometheus-server.
Deployed Grafana nginx-mesh/grafana.
Deployed tracing server nginx-mesh/zipkin.
All resources created. Testing the connection to the Service Mesh API Server...
Connected to the NGINX Service Mesh API successfully.
NGINX Service Mesh is running.For more options, including advanced settings, run this command:
$ nginx-meshctl deploy βhCheck that the control plane works correctly in the namespace nginx mesh, you can:
$ kubectl get pods βn nginx-mesh
NAME READY STATUS RESTARTS AGE
grafana-6cc6958cd9-dccj6 1/1 Running 0 2d19h
mesh-api-6b95576c46-8npkb 1/1 Running 0 2d19h
nats-server-6d5c57f894-225qn 1/1 Running 0 2d19h
prometheus-server-65c95b788b-zkt95 1/1 Running 0 2d19h
smi-metrics-5986dfb8d5-q6gfj 1/1 Running 0 2d19h
spire-agent-5cf87 1/1 Running 0 2d19h
spire-agent-rr2tt 1/1 Running 0 2d19h
spire-agent-vwjbv 1/1 Running 0 2d19h
spire-server-0 2/2 Running 0 2d19h
zipkin-6f7cbf5467-ns6wc 1/1 Running 0 2d19hNGINX sidecars proxies will be added to applications by default depending on deployment settings that set manual or automatic injection policies. To disable automatic addition, read
For example, if we deploy the application Sleep in namespace default, and then check the Pod - we will see two running containers, the application Sleep and its associated sidecar:
$ kubectl apply βf sleep.yaml
$ kubectl get pods βn default
NAME READY STATUS RESTARTS AGE
sleep-674f75ff4d-gxjf2 2/2 Running 0 5h23mAlso we can follow the application Sleep in an NGINX Plus panel by running this command to access sidecar from your local machine:
$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886Then we just go in the browser. You can also connect with Prometheus to follow the app Sleep.
You can use individual Kubernetes resources to configure traffic policies such as access control, rate limiting, and circuit breaking, see
Conclusion
NGINX Service Mesh is available for free download at . Try it out in your dev and test environments and .
To try NGINX Plus Ingress Controller, activate for 30 days, or to discuss your use cases.
Translation by Pavel Demkovich, company engineer . System administration for 15 β½ per month. And as a separate division - a training center , practice and nothing but practice.
Source: habr.com