Skip to main content

Google Load Balancing Controller

PLATFORM

This reference solution highlights the integration of* cert-manager*, the de-facto machine identity management component in Kubernetes clusters and GKE Ingress Controller, where SSL offloading takes place in an GKE cluster equipped with Google Cloud Load Balancing. This integration enables organizations running cloud native workloads and serving HTTPs traffic with* Google Cloud Load Balancing* the ability to automate and secure the lifecycle of TLS certificates using policies defined by security teams and ensure the extension of security policies to Kubernetes resources. This integration is enabled through Kubernetes resource configuration. Release and support versions Google Load Balancing Controller (GLBC) is part of Kubernetes community. There are no specific version requirements on cert-manager and GLBC. However, there is a version mapping between k8s and GLBC. Please see: https://github.com/kubernetes/ingress-gce** Applicability** Any organization running clusters in GKE and taking advantage of Google Cloud Load Balancing as layer 7 load balancers to manage the HTTPs requests that client applications send to web apps that are hosted on a pool of web servers should consider deploying this integration to automate the management of machine identities consumed by Google Cloud Load Balancing.** Special notes and limitations** There is a reference specification for ingress controllers which allows securing an Ingress implementation by specifying a Secret that contains a TLS private key and certificate. cert-manager is aware and knows where and how to retrieve the Secret, therefore, able to operate on the TLS private key and certificate. The configuration-only based integration with Kubernetes ingresses is not limited to GLBC.* cert-manager* can integrate with all ingresses that implement the reference specification for ingress controller. This includes the three controllers supported and maintained by Kubernetes, AWS Load Balancer Controller, ingress-nginx and the following third-party ingresses: - Kong Ingress Controller for Kubernetes - Azure Application Gateway Ingress Controller - Istio Ingress - Traefik Kubernetes Ingress provider - Citrix Ingress Controller - Apache APISIX ingress controller - Gloo - NGINX Ingress Controller for Kubernetes - Avi Kubernetes Operator - HAProxy Ingress - Pomerium Ingress Controller This list is always growing and changing by Ingress providers, for the latest version, check out the third-party ingress controllers link in “Additional resources”.

ADDITIONAL RESOURCES

GETTING STARTED

There are two ways to configure the ingress controller via the ingress resource configuration after the successful creation of the ingress which tells GKE to use Google Cloud Load Balancing as the Ingress. Method 1: annotation apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: #NAME_YOUR_INGRESS annotations: Kubernetes.io/ingress.class: “ingress-gce” Method 2: spec attribute “ingressClassName” apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: #NAME_YOUR_INGRESS spec: ingressClassName: ingress-gce

ABOUT Google Cloud Load Balancing

Cloud Load Balancing is a fully distributed, software-defined managed service. It isn't hardware-based, so you don't need to manage a physical load-balancing infrastructure. Cloud Load Balancing is built on the same frontend-serving infrastructure that powers Google. It supports 1 million+ queries per second with consistent high performance and low latency. By using Cloud Load Balancing, you can serve content as close as possible to your users. Traffic enters Cloud Load Balancing through 80+ distinct global load-balancing locations and stays on Google's fast private network backbone for most of its journey. If it's needed, traffic is handed off to the public internet as close as possible to your users.

Certificate Manager, Self-Hosted is the product formerly known as Venafi Trust Protection Platform