nxs-universal-chart: Helm Chart to Simplify Kubernetes Operations

Introduction

Managing Kubernetes infrastructure can feel overwhelming, especially with the multitude of tools and configurations required for tasks like routing, load balancing, and secure communication. nxs-universal-chart emerges as a unified solution, designed to simplify these complexities. By integrating support for Istio resources, Ingress controllers, and Kubernetes routing, this Helm chart offers a streamlined approach to managing your cluster infrastructure.

This article consolidates key insights and examples from four detailed guides, showing how nxs-universal-chart can be a game-changer for your Kubernetes workflows.

The Core Idea Behind the tool
At its heart, nxs-universal-chart is about unification and simplicity. By offering a single Helm chart that encapsulates the configuration of multiple Kubernetes components, it eliminates the need for separate, potentially conflicting setups. Whether you’re dealing with Istio’s complex routing or setting up Ingress controllers, this chart provides a consistent and efficient way to handle it all.

Cert-manager resources

Our chart now supports cert-manager custom resources. We’ve added a template to create custom resources that implements Issuer, ClusterIssuer, and Certificate objects. These Kubernetes resources represent certificate authorities that can generate signed certificates by request and ensure they’re valid and up-to-date, which we find cool and useful for a great number of cases. Along with that, now a simple web application creates these resources.

You need to add a template to create custom resources implements Issuer (ClusterIssuer also) and Certificate objects. Add a simple web application that creates these resources (create selfsigned issuer and certificate) and uses them as Ingress SSL certificates. To deploy it, run helm install f ./ — values ./samples/whoami-with-certs.yml.

Commands for a test run in down below:

❯ cmctl status certificate f-whoami.example.com-tls
Name: f-whoami.example.com-tls
Namespace: default
Created at: 2023-05-02T22:54:00+03:00
Conditions:
  Ready: True, Reason: Ready, Message: Certificate is up to date and has not expired
DNS Names:
- whoami.example.com
Events:
  ...
Issuer:
  Name: f-selfsigned-ca-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: KeyPairVerified, Message: Signing CA verified
  Events:
    ...
Secret:
  Name: f-whoami.example.com-tls
  Issuer Country:
  Issuer Organisation:
  Issuer Common Name: selfsigned-ca
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages:
  Public Key Algorithm: RSA
  Signature Algorithm: ECDSA-SHA256
  Subject Key ID:
  Authority Key ID: 862c30b38c6cdb81157cf1c08a0620b5b5dc3023
  Serial Number: d6a224f353104ea404a63f2792980966
  Events:  <none>
Not Before: 2023-05-02T22:54:06+03:00
Not After: 2023-07-31T22:54:06+03:00
Renewal Time: 2023-07-01T22:54:06+03:00
No CertificateRequest found for this Certificate

❯ certinfo --insecure whoami.example.com:443
--- [whoami.example.com:443 TLS 1.3] ---
Version: 3
Serial Number: 285296692633950831302078139990680275302
Signature Algorithm: ECDSA-SHA256
Type: end-entity
Issuer: CN=selfsigned-ca
Validity
    Not Before: May  2 19:54:06 2023 UTC
    Not After : Jul 31 19:54:06 2023 UTC
Subject:
DNS Names: whoami.example.com
IP Addresses:
Authority Key Id: 862c30b38c6cdb81157cf1c08a0620b5b5dc3023
Subject Key Id  :
Key Usage: Digital Signature, Key Encipherment
Ext Key Usage:
CA: false

The first command gets metadata about the certificate from k8s resource via cmctl tool. The second one is certinfo print information about the certificate from the remote host (Ingress). Identical values in the field Authority Key Id tell us that the certificates match.

Istio Integration

For advanced networking needs, the chart integrates seamlessly with Istio, enabling configurations for Gateway, VirtualService, and DestinationRule.

Gateway is a gateway that describes a load balancer and handles incoming or outgoing HTTP/TCP connections. It is a kind of “gateway” through which all external requests pass before reaching the inside of the Kubernetes cluster.

Istio Gateway

---
# Source: universal-chart/templates/istiogateway.yml
apiVersion:
kind: Gateway
metadata:
  name: nginx-gateway
  namespace: "test"
  labels:
    app.kubernetes.io/name: test
    app.kubernetes.io/instance: test
    helm.sh/chart: universal-chart-2.8.0
    app.kubernetes.io/managed-by: Helm
  annotations:
spec:
  selector:
    istio: ingress
  servers:
  - hosts:
    - nginx.example.com
    port:
      name: http
      number: 80
      protocol: HTTP

VirtualService
VirtualService operates on a set of rules when accessing the host, which is used to establish: which services or pods to send traffic to, the need to run canary deployment or A/B testing, etc. The source of traffic can also be specified in routing rules. This allows routing to be customized for specific client contexts. In simpler terms, VirtualService describes a packet's routing to our application's desired Kubernetes Service.

---
# Source: universal-chart/templates/istiovirtualservice.yml
apiVersion:
kind: VirtualService
metadata:
  name: nginx-virtualservice
  namespace: "test"
  labels:
    app.kubernetes.io/name: test
    app.kubernetes.io/instance: test
    helm.sh/chart: universal-chart-2.8.0
    app.kubernetes.io/managed-by: Helm
  annotations:
spec:
  hosts:
    - "nginx.example.com"
  gateways:
    - "nginx-gateway"
  http:
    - name: ""
      match:
        - uri:
            prefix: /
      route:
        - destination:
            host: nginx-service.default.svc.cluster.local
            port:
              number: 80

DestinationRule

It specifies policies for traffic such as load balancing, distributing traffic between service instances, error management, fault tolerance policies (timeouts, retries, any other reliability measures), routing traffic to different versions of the application, etc. that will be applied to traffic destined to instances of this service.

---
# Source: universal-chart/templates/istiodestinationrule.yml
apiVersion:
kind: DestinationRule
metadata:
  name: nginx-destinationrule
  namespace: "test"
  labels:
    app.kubernetes.io/name: test
    app.kubernetes.io/instance: test
    helm.sh/chart: universal-chart-2.8.0
    app.kubernetes.io/managed-by: Helm
  annotations:
spec:
  host: "nginx-service.default.svc.cluster.local"
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 500
        maxRequestsPerConnection: 50
    loadBalancer:
      simple: ROUND_ROBIN
    outlierDetection:
      baseEjectionTime: 15s
      consecutiveGatewayErrors: 3
      interval: 5s
  subsets:
    - name: v1
      labels:
        app: "nginx"
      trafficPolicy:
        connectionPool:
          tcp:
            maxConnections: 200
        loadBalancer:
          simple: LEAST_CONN
    - name: v2
      labels:
        version: "v2"
      trafficPolicy:
        connectionPool:
          http:
            http2MaxRequests: 2000
        loadBalancer:
          simple: RANDOM
  exportTo:
    - "."
    - "another-namespace"

Ingress Controllers

The chart includes support for popular Ingress controllers like NGINX and Traefik, allowing you to easily configure routing rules.

Example Configuration:
To manage timeouts and certificates, you can use the ServersTransport resource in Traefik, which allows you to set connection and data transmission timeouts, as well as how to use secrets for storing root certificates:

kind: ServersTransport
apiVersion: traefik.io/v1alpha1
metadata:
  name: default
  labels:
    app.kubernetes.io/name: test
    app.kubernetes.io/instance: test

    helm.sh/chart: nxs-universal-chart-2.8.1
    app.kubernetes.io/managed-by: Helm
spec:
  forwardingTimeouts:
    dialTimeout: 42s
    idleConnTimeout: 42s
    responseHeaderTimeout: 42s
  rootCAsSecrets:
  - ca-secret

This manifest demonstrates how to control connection timeout and response header delay, which is especially useful for managing network latency and ensuring service stability.

Key Advantages of nxs-universal-chart

1. Flexibility with Customization
   The chart accommodates a wide range of use cases, from basic routing to complex Istio setups.

2. Standardized Workflows
   With consistent templates and configurations, teams can reduce errors and speed up deployments.

3. Broad Compatibility
   nxs-universal-chart works seamlessly with multiple Kubernetes ecosystems, making it a versatile tool for diverse environments.

4. Time-Saving Automation
   By consolidating configurations into one chart, teams can eliminate repetitive tasks, focusing on what truly matters—delivering reliable services.

Why It Matters

Modern DevOps practices emphasize automation, standardization, and scalability. nxs-universal-chart aligns with these goals, enabling teams to:

• Reduce configuration overhead.

• Maintain consistency across deployments.

• Handle complex networking with ease.

By using a single Helm chart, teams can focus on delivering business value instead of wrestling with Kubernetes intricacies.

Conclusion

In the rapidly evolving Kubernetes ecosystem, tools like nxs-universal-chart are essential for simplifying operations. Whether you’re a small team just starting with Kubernetes or an enterprise managing large-scale deployments, this Helm chart offers the flexibility, reliability, and ease of use you need to succeed.

By consolidating the management of Istio, Ingress, and other resources into a single solution, nxs-universal-chart is a step forward in the journey towards more streamlined and efficient Kubernetes workflows.

But we also want to share our work with the community to make the nxs-universal-chart even better and more convenient, and to give you more free time.

You can also join the telegram channel and the chat to keep track of updates or ask any questions you might have!