This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Overview

You can control how network traffic flows within your GKE clusterby using GKE Service Steering. You can define rules to directspecific types of traffic to network functions that you've deployed in yourcluster. GKE Service Steering is similar to policy-based routing,where you override the normal path of the network traffic.

Terminology and concepts

This page uses the following concepts:

Service Function (SF)

AService Function is a software component that works on the received datapackets. A Service layer can operate at any layer of the OSI model startingLayer 2 (data link layer).

Service Functions can be broadly categorized into the following:

• Firewalls for security
• Proxies for controlling access
• WAN acceleration for improving speed,
• Deep Packet Inspection (DPI) for analyzing content
• Lawful Intercept (LI) for surveillance and investigation
• Network Address Translator (NAT) for private and public IP addresses
• HTTP for header enrichment
• Load balancers for distributing traffic efficiently

Alternate terminologies for Service Functions include:

• Container appliances
• Virtual appliances
• Virtualized network functions (NFVs)
• Containerized network functions (CNFs)
• Cloud-native network functions (CNFs)

In Service Steering, a Service object represents a Service Function (SF).

Service Function Chain (SFC)

Service Function Chain (SFC) is a series ofService Functionssuch as firewalls, proxies, or load balancers linked together to process networktraffic in specific order. This chain acts like a pipeline, where each ServiceFunction performs a particular task on the traffic before passing it onto thenext function.

Service Function Chain (SFC) is also called Service Chain (SC).

In Service Steering,ServiceFunctionChain object represents a ServiceFunction Chain (SFC).

A Service Function operates independent of any Service Function Chain. ServiceFunction is typically unaware of which Service Function Chains it's part of.

Service Steering

Service Steering routes packets to the selected Service Function in a way that iscompletely transparent to the source and destination. This concept is sometimesreferred to as "policy-based routing", "traffic redirection", or "ServiceFunction forwarding". Service Steering achieves the transparent routing usingGeneve + NSH encapsulation (seeRFC8926,RFC8300,Geneve + NSH IETFDraft).

Some of the important characteristics of Service Steering include:

• Load balancing across a Service Function's backend Pods: ServiceFunctions often run on multiple Pods for scalability and reliability.Service Steering distributes incoming network traffic evenly across thesePods to prevent any single Pod from becoming overloaded.
• Supporting 5-tuple flow affinity (all intermediate hops must be stable fora given flow): A 5-tuple flow is a way of identifying a specific stream ofnetwork traffic based on source IP address, source port, destination IPaddress, destination port, and protocol. Service Steering ensures that allpackets within the same flow are consistently directed to the same set ofService Functions (hops).
• Enabling a symmetric return datapath: A symmetric return datapath meansthat the response traffic follows the same path back to the source as theoriginal request traffic did. Service Steering ensures this symmetry, whichis important for some network protocols and applications.

For any given network traffic that's being service steered, the intermediateService Function Pods handle all the packets of that particular network trafficensuring consistent intermediate hops and predictable route. The same ServiceFunction Pods receives the return traffic to ensure symmetric traffic flow.If the original traffic is sent to a destination within the same cluster, thereturn traffic automatically finds a way back through the same Service Chain. Ifthe original traffic is outside the cluster, the final Service Function in thechain attracts the traffic back to itself using either source network addresstranslation (SNAT) or a proxy, which acts as an intermediary.

Use cases

GKE Service Steering integrates policy-based routing into yourclusters. This enables the following primary use cases:

Self-managed security services:

Organizations can construct their own security infrastructure usingcontainerized network functions (CNFs) such as virtual firewalls (vFWs), virtualnext-generation firewalls (vNG-FWs), and virtual intrusion detection systems(vIDSs). Service Steering ensures that traffic is routed through these CNFsbefore reaching its intended destination, providing a layer of protection andcontrol.

Managed security providers (MSPs):

MSPs can utilize GKE Service Steering to route your trafficthrough their cloud-based security Service Chains. This allows them to offercomprehensive security solutions, including Secure Web Gateways (SWGs), SASE(Secure Access Service Edge), and SD-WAN (Software-Defined Wide Area Network)functionalities.

Telecommunications and 5G Networks:

Service Steering manages traffic flows for various network functions withintelecom and 5G infrastructures. You can orchestrate virtual routers (vRouters),virtual session border controllers (vSBCs), and 5G core network functions toensure efficient traffic management, load balancing, and the enforcement ofspecific security or quality of Service policies.

How Service Steering works

This section describes how various components of Service Steering works.

Service Function

1. Identifies network traffic flow: GKE Service Steeringidentifies each network connection by using a unique flow ID, a 5-tuple hashof the packet's source IP address, source port, destination IP address,destination port, and protocol.

2. Ensures flow affinity: Service Steering ensures flow affinity bydirecting all packets with the same flow ID through the same path of ServiceFunctions (SFs).

3. Modifies packets to create new flows: If an Service Function modifiesany of the 5-tuple fields in a packet. For example, NAT changing the sourceIP address, this creates a new flow.

4. Selects traffic for new flows: Traffic selection process evaluates thenew flow to determine its path through the remainingService Functions,potentially taking a different route than the original flow.

5. Handles proxies and NATs as two flows: Traffic through proxies or NATsis considered as two separate flows: source to proxy/NAT and proxy/NAT todestination. Service Steering doesn't guarantee the same path for these twoflows.

6. Validates source address: SFs are always subject to source addressvalidation, even for traffic not steered by Service Steering. If an ServiceFunction originates a new flow with a mismatched source IP address, thosepackets are dropped unless explicitly allowed.

7. Maintains encapsulation transparency: Service Steering uses Geneveencapsulation for traffic between SFs, but Service Function Pods themselvesare unaware of it. Packets are decapsulated before entering the Pod,simplifying Service Function development.

Existing connections

When you create aTrafficSelector, Service Steering automatically applies itto any existing connections that match the selector's criteria. It redirectspackets from these connections to the appropriate service functions. The ServiceFunction itself is responsible for managing these in-flight connections. Acommon approach is to drop the packets and rely on the client to initiate a newconnection, which then seamlessly integrates into the service chain from thebeginning.

Resource lifecycle

BothTrafficSelector andServiceFunctionChain resources are deletedimmediately after they're marked for deletion. There are no webhooks orfinalizers that prevent or delay resource deletion.

Pod-to-Service traffic

Service Steering performs traffic selection after it resolves the ServiceVirtual IP address. The traffic directed to a Service using its ClusterIP can beselected for Service Steering if the destination Pod's IP address falls withinthe CIDR specified in the.egress.to.ipBlock field after the Virtual IPaddress is resolved.

NetworkPolicy enforcement

Service Steering does not bypassNetworkPolicy. Egress policy at the sourcePod and ingress policy at the destination Pod still apply to traffic selectedfor Service Steering. However, it is not subject toNetworkPolicy enforcementat the ingress or egress of a Service Function. This is because the ingress oregress rules ofNetworkPolicy are well-defined for source and destinationPods, but not packet forwarders.

Benefits

The adoption of GKE Service Steering, coupled with the transitionto cloud-native technologies, has the following benefits:

• Marketplace offering: Third Parties can offer their containerizedproduct on Google Cloud Marketplace and use the Service Steering APIs. They canprovide a deployment guide based on Kubernetes built-in API provided andmanaged by GKE.
• Kubernetes granularity: You can control traffic within your Kubernetescluster. You can classify traffic that you want to steer. You can selectworkloads where you want Service Steering selectively applied.
• Bidirectionality: GKE's Service Steering isbidirectional in nature. This means that for a given flow, the return pathis symmetrical to the forward path. This is important when the ServiceFunctions (SFs) are being deployed as a group of replicas. Ensurethat the same flow goes through the same set Replica so as to maintainstatefulness.
• Multi-Network support: A majority of Service Functions require multiplePod interfaces for separation of dataplane from control and managementplane. Some Service Functions have multiple interfaces as part of theirarchitecture. GKE's Service Steering includes integrationwith Multi-Network on Pods. With this, a user can create a Service Steeringon a specific Pod-Network.
• Raw Packet Delivery to Application: GKE's ServiceSteering encapsulates the original packet and delivers it to the Poddirectly. This way you don't have to do any decapsulation and yourapplication can act on the original packet directly.

What's next

• Control network traffic flows using Service Steering