Ingress for Anthos—Multi-cluster Ingress and Global Service Load Balancing

Ingress for Anthos—Multi-cluster Ingress and Global Service Load Balancing

  • September 18, 2020
Table of Contents

Ingress for Anthos—Multi-cluster Ingress and Global Service Load Balancing

Ingress for Anthos is a Google cloud-hosted multi-cluster ingress controller for Anthos GKE clusters. Ingress for Anthos supports deploying shared load balancing resources across clusters and across regions enabling users to use a same load balancer with an anycast IP for applications running in a multi-cluster and multi-region topology. In simpler terms this allows users to place multiple GKE clusters located in different regions under one LoadBalancer.

It’s a controller for the external HTTP(S) load balancer to provide ingress for traffic coming from the internet across one or more clusters by programming the external HTTP(S) load balancer using network endpoint groups (NEGs). NEGs are useful for Container native load balancing where each Container can be represented as endpoint to the load balancer. Taking advantage of GCP’s 100+ Points of Presence and global network, Ingress for Anthos leverage GCLB along with multiple Kubernetes Engine clusters running across regions around the world, to serve traffic from the closest cluster using a single anycast IP address.

Source: itnext.io

Share :
comments powered by Disqus

Related Posts

Introducing PodTopologySpread

Introducing PodTopologySpread

Managing Pods distribution across a cluster is hard. The well-known Kubernetes features for Pod affinity and anti-affinity, allow some control of Pod placement in different topologies. However, these features only resolve part of Pods distribution use cases: either place unlimited Pods to a single topology, or disallow two Pods to co-locate in the same topology.

Read More
Building a Kubernetes platform at Pinterest

Building a Kubernetes platform at Pinterest

Over the years, 300 million Pinners have saved more than 200 billion Pins on Pinterest across more than 4 billion boards. To serve this vast user base and content pool, we’ve developed thousands of services, ranging from microservices of a handful CPUs to huge monolithic services that occupy a whole VM fleet. There are also various kinds of batch jobs from all kinds of different frameworks, which can be CPU, memory or I/O intensive.

Read More