Network configurations

In Deckhouse Code, when installed in a Kubernetes cluster, the following network configuration options are used:

1. Configuration with an additional LoadBalancer for the web service and shell service: When the spec.network.ownLoadBalancer.enabled parameter of CodeInstance custom resource is set to true, the Haproxy component is deployed with a Service of type LoadBalancer. The Service accepts HTTP, HTTPS, and Git over SSH on a single external IP address via 80, 443, and 22 ports, respectively. Haproxy forwards traffic from port 22 to the corresponding Git SSH Pod. Ports 80 and 443 are handled by the Ingress controller, where TLS traffic is terminated. A separate IP address is also allocated, distinct from the Ingress controller’s IP address. A separate DNS record must be created for this address. The following services will be accessible via this DNS record:

   • Web interface (UI) on ports 80 and 443
   • Git SSH on port 22

   This network configuration is the default one. For more details on configuring the additional load balancer, refer to the code module documentation.

2. Configuration without an additional LoadBalancer: When the spec.network.ownLoadBalancer.enabled parameter of CodeInstance custom resource is set to false, the Ingress controller is used to access the web interface (UI) and other services via standard HTTP (80) and HTTPS (443) ports. However, the Ingress controller does not support TCP port proxying. Therefore, to access Git SSH via port 22, a separate service of LoadBalancer or NodePort type is used.

Architecture

The Level 2 C4 architecture of Deckhouse Code network configurations is shown in the following diagrams.

With an additional LoadBalancer for the web and shell services:

Without an additional LoadBalancer:

Using the Istio service mesh

When this mode is enabled, the operator switches all internal communication between Deckhouse Code components from application‑level TLS to Istio mTLS (provided by Envoy sidecars). The operator also creates a PeerAuthentication resource to enforce mTLS.

When running in the Istio service mesh, Deckhouse Code has following architecture specifics:

• Istio-proxy sidecar containers are injected to the pods of all Deckhouse Code components.

• The following components are switched to operate over the HTTP protocol:

  • Gitlab-workhorse: Port 8181 remains unchanged.
  • Gitlab-webservice: Port 8081 is changed to 8080.
  • Gitaly: Port 8076 is changed to 8075.
  • Praefect: Port 8076 is changed to 8075.

• Internal TLS certificates for Webservice, Gitaly, and Praefect are removed.

• Traffic of all Deckhouse Code components is intercepted by Envoy sidecars, except for traffic on the following ports of the Haproxy component:

  • Inbound traffic on ports 8080, 4443, and 2222.
  • Outbound traffic on port 443.

• Ports of some components are configured in PERMISSIVE.

• When PeerAuthentication is set to STRICT, the Ingress NGINX Controller must be in the Istio mesh to reach the web UI. For details on injecting sidecars for the ingress-nginx module, refer to “Enabling Istio for applications”.

• The Gitaly Service operates in headless mode (clusterIP: None).

For more details on how Deckhouse Code works in the Istio service mesh, refer to the code module documentation.