Kube-Proxy in Thalassa Cloud Kubernetes

Kube-Proxy is a network proxy component that runs on each node in a Kubernetes cluster, implementing part of the Kubernetes Service concept. It maintains network rules on nodes, allowing network communication to your Pods from network sessions inside or outside of your cluster.

In Thalassa Cloud Kubernetes, kube-proxy can be configured with different proxy modes and deployment types, providing flexibility based on your networking requirements and CNI choice.

How Kube-Proxy Works

Kube-Proxy is responsible for implementing the Kubernetes Service abstraction by maintaining network rules that forward traffic to the appropriate backend Pods. It watches the Kubernetes API server for changes to Services and Endpoints, and updates the network rules accordingly.

Kube-Proxy provides several essential functions, including distributing traffic across Pods that match a Service’s selector (service load balancing), maintaining iptables or IPVS rules to route traffic appropriately (network rules management), enabling Pods to access Services using stable DNS names and IP addresses (service discovery), and supporting client IP-based session affinity for Services.

Configuration Options

Thalassa Cloud Kubernetes provides several configuration options for kube-proxy:

Proxy Modes

Kube-Proxy can operate in different modes, each with its own characteristics:

Proxy ModeDescriptionUse Case
IPVS (Default)Uses IP Virtual Server for load balancing. More efficient for large clusters with many services.Recommended for production clusters with high service counts
IPTablesUses iptables rules for load balancing. More compatible but can be slower with many services.Suitable for smaller clusters

Deployment Types

You can configure how kube-proxy is deployed and managed:

Deployment TypeDescription
ManagedThalassa Cloud fully manages kube-proxy deployment and configuration
CustomYou manage kube-proxy deployment and configuration yourself
Disabledkube-proxy is not deployed. Requires a CNI that provides kube-proxy replacement functionality or manual Kube Proxy deployment

Integration with Cilium

When using Cilium as your CNI, you have the option to disable kube-proxy and use Cilium’s kube-proxy replacement mode instead.

Cilium Kube-Proxy Replacement

If kube-proxy is disabled and Cilium CNI is enabled, Cilium automatically configures itself to run with kube-proxy replacement mode. This provides:

  • Better Performance: eBPF-based service handling is more efficient than traditional kube-proxy
  • Reduced Resource Usage: Eliminates the need for a separate kube-proxy component
  • Enhanced Observability: Better integration with Cilium’s observability features

Recommendation

Thalassa Cloud recommends running with Cilium and kube-proxy disabled for optimal performance and resource efficiency.

Custom CNI Considerations

If you have a custom CNI that doesn’t provide kube-proxy replacement functionality, you are responsible for configuring and deploying kube-proxy or a suitable replacement. Ensure your CNI is compatible with Thalassa Cloud’s networking features.

Checking Kube-Proxy Status

To verify if kube-proxy is running in your cluster:

kubectl get pods -n kube-system | grep kube-proxy

If kube-proxy is enabled, you should see pods running on each node.

To check the current proxy mode:

kubectl get configmap kube-proxy -n kube-system -o yaml | grep -i mode

Configuration Changes

Changing Proxy Mode

You can change the proxy mode between IPVS and IPTables based on your requirements.

Important

Adjusting the proxy mode only affects new nodes, not nodes already available in the cluster. Existing nodes will continue using the previous proxy mode until they are replaced or the kube-proxy pods are manually restarted.

Changing Deployment Type

You can toggle between Managed, Custom, and Disabled deployment types.

Important

Toggling the ProxyMode or Deployment Type doesn’t fully reload all components. After toggling the settings, you are responsible for restarting Cilium agents and kube-proxy pods to ensure the changes take effect.

Restarting Components

After making configuration changes, restart the affected components:

# Restart kube-proxy pods
kubectl delete pods -n kube-system -l k8s-app=kube-proxy

# If using Cilium, restart Cilium agents
kubectl delete pods -n kube-system -l k8s-app=cilium

Troubleshooting

Service Not Accessible

If Services are not accessible:

  1. Check kube-proxy pods are running:

    kubectl get pods -n kube-system -l k8s-app=kube-proxy
  2. Check kube-proxy logs:

    kubectl logs -n kube-system -l k8s-app=kube-proxy
  3. Verify Service endpoints:

    kubectl get endpoints <service-name>

Cilium Kube-Proxy Replacement

If using Cilium with kube-proxy disabled:

  1. Verify Cilium is in kube-proxy replacement mode:

    kubectl exec -n kube-system <cilium-pod> -- cilium status
  2. Check Cilium logs:

    kubectl logs -n kube-system -l k8s-app=cilium

Known Issues and Limitations

Configuration Changes

  • Incomplete reload: Toggling ProxyMode or Deployment Type doesn’t fully reload all components. Manual restart of Cilium agents and kube-proxy pods is required after changes.
  • Node-level changes: Adjusting the proxy mode only affects new nodes, not existing nodes in the cluster.

Workarounds

After making configuration changes:

  1. Restart kube-proxy pods: kubectl delete pods -n kube-system -l k8s-app=kube-proxy
  2. Restart Cilium agents (if applicable): kubectl delete pods -n kube-system -l k8s-app=cilium
  3. For proxy mode changes, consider replacing nodes or waiting for node rotation

Additional Resources