HTTP Sidecar

There are two ways to implement a complete distributed microservices application with Light in a Kubernetes cluster: Embedded and Sidecar.

If you use Java 8 or Java 11 to implement your service, you can leverage one of the Light frameworks with cross-cutting concerns embedded in the request/response chain.

The other option is to use the HTTP Sidecar container in the same pod to address the cross-cutting concerns at the network level.

The http-sidecar is a combination of light-proxy and light-router to manage the cross-cutting concerns for the incoming and outgoing traffic of backend API in the same pod in a Kubernetes cluster.

  • Package and deployed as a separate module to handle Cross-Cutting Concerns for the main container/service in the same pod. In this case, the main service only need care about the HTTP request/response and business logic

  • Ingress traffic: First, client API requests will come to the sidecar service. Sidecar service acts as a proxy to delegate light client features, including open API schema validation, observability, monitoring, logging, JWT verify, etc. Then forward the request to the main service.

  • Egress traffic: The main service calls the sidecar service first for egress traffic; in this case, the sidecar service acts as a router to delegate light client features, including service discovery, SSL handshake, JWT token management, etc. Then forward the request to server API. Here are several egress configuration properties that need to be considered.

Suppose an organization has made the decision to standardize with the sidecar approach. In that case, we highly recommend light-4j frameworks for backend API implementation for smooth integration with the HTTP Sidecar if Java 8 or Java 11 is the target language. However, users can build the backend API with any language and framework as the sidecar is deployed independently.

You can deploy the HTTP Sidecar in the same container as the backend API or a separate container. We recommend the separate container approach based on the analysis in the deploy patterns.

When the http-sidecar is used, all the traffic to and from the pod should go through the sidecar, and the network policy will be defined to control the access.

There are some special considerations for the configurations for the http-sidecar when deploying it with a backend API in the same pod in a Kubernetes cluster.

For most enterprise applications, sensitive data in the logs should be masked. It is easier to do that in the http-sidecar as a mask module is included. However, the masking must be handled differently for the backend API implemented in other Java frameworks or other languages. To support masking for the backend logs, we can send the backend logs to the http-sidecar, and http-sidecar can do the log masking before injecting the log files to the target indexing app or pushing the logs to a Kafka cluster for streams processing.

We need to deploy a multiple-container pod using the sidecar in a Kubernetes cluster. It will become more complicated when replicas, sealed secrets, network policies, auto scalers are involved. Instead of using the Helm for templating or Kustomize for patching, we leverage the light-config-server to manage the templates and light-bot to do the Kubernetes deployment.

Egress Configuration

Caller Backend When your backend API is calling another API, your backend needs to put the target service_id or service_url as a header in the request. If your network policy supports HTTP, use the HTTP URL; otherwise, use the HTTPS URL. For example, you can use the following URL in the request header to access the Petstore Sidecar in the same K8s cluster. service_url: https://petstore.dev-test-ns Or service_id: com.networknt.petstore-1.0.0 Instead of calling the sidecar of the downstream API, call your sidecar with the local host with HTTP protocol in the same pod. Read More »

K8s Deployment

When working on complicated Kubernetes deployment, we need to choose a deployment engine. There are two types: Templating Engine and Overlay Engine. Helm is the best implementation of Templating Engine, and Kustomize is the best implementation of the Overlay Engine. Here are the pros and cons of each tool. Features Kustomize Helm Native K8s integration Yes No Overlays Yes No Visibility and transparentcy Strong Weak Packaging No Yes Version control, rollbacks No Yes Templating No Yes Target user DevOps Developer The most important is the target user with all the pros and cons above. Read More »

Log Masking

Most log masking modules can only handle the masking with Regex, and it is not enough in a complicated JSON object logging. We need to define the Regex with JSONPath to identify the masking data. Light-4j mask module supports String, Regex and JSON masking with a configuration file mask.yml customized for a particular API. To leverage that, we can allow the backend API to send the logs to the http-sidecar for masking before ingesting them to the target indexing system. Read More »

Health Check

When deploying the http-sidecar along with a backend API in the same pod in a Kubernetes cluster, we need to have two health check endpoints injected into the OpenAPI specification on the sidecar. And a special health check handler will be used instead of the standard health check handler in light-4j. /health/${server.serviceId}: get: description: The light-4j ProxyHealthGetHandler that is optionally invoke the backend API security: - admin-scope: # for control pane to access all businesses' admin endpoints - admin # for each business to access their own admin endpoints - ${server. Read More »

Kubernetes Config

When using the http-sidecar within a Kubernetes cluster, there are some configuration considerations: logback.xml This is the file used to set up the logging level on the http-sidecar and it should have a copy per environment in the overlays folder with the following reasons. Although the http-sidecar has the logger config endpoints to change the logging level from the control plane, we usually pass through the request to the backend API in the same pod. Read More »

Network Policy

When http-sidecar is used, all the traffic to and from the pod should go through the sidecar for API invocation and invoke other APIs. Here is an example network policy on the Kubernetes cluster. networkpolicy.yaml kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: proxy-allow labels: app: api spec: podSelector: matchLabels: app: api ingress: - from: - namespaceSelector: {} podSelector: {} ports: - protocol: TCP port: 8080 egress: - to: ports: - protocol: TCP port: 8438 - protocol: TCP port: 443 - protocol: TCP port: 8443 - protocol: TCP port: 53 - protocol: UDP port: 53 policyTypes: - Ingress - Egress For ingress rules, it allows both North-South traffic from the Internet with ingress-nginx, for example, and east-west traffic between APIs within the same Kubernetes cluster regardless of the namespace on port 8080. Read More »

Deploy Patterns

The sidecar approach has a separate backend API process compared with the embedded cross-cutting concerns in the same process. We can deploy the two processes in the same container or the sidecar process in a different container in a pod. Putting the sidecar and backend API in the same container can reduce the resource usage overall, as an additional container will have its OS. However, there are several benefits if the sidecar is in its own container. Read More »