Use Cases
By using extra node label, you can directly forward a request to a Pod with the specified label under a service so as to finely control the target Pod.
For example, in the default
namespace, there are a Pod with labels of app: httpbin
and version: v1
, a Pod with labels of app: httpbin
and version: v2
, as well as an httpbin service with selector of app: httpbin
. If you want API Gateway to only forward requests to the Pod whose labels are app: httpbin
and version: v1
, you can use the extra node label and add the configuration of version: v1
to achieve this.
Directions
1. When configuring the TKE tunnel, manually enter the extra node label.
2. Click Save to create or modify the TKE tunnel.
The final effect of forwarding is as follows:
How It Works
In a TKE cluster, the service itself is configured with selectors. For example, in the httpbin service, the selector is app: httpbin
, but the extra node label provided by API Gateway will be combined with the selector in the httpbin service, so the final label combination will be app: httpbin
and version: v1
. Therefore, only the http Pod with the version: v1
label will appear as this TKE tunnel's node.
If you enter a label key that already exists in the httpbin service in the extra node label, the extra node label will be ignored, and the value of the label existing in the selector will prevail. For example, if you enter app: not-httpbin
in the extra label, it will conflict with the selector of the httpbin service, so app: not-httpbin
will be ignored.
The YAML of the httpbin service is as follows:
apiVersion: v1
kind: Service
metadata:
name: httpbin
labels:
app: httpbin
service: httpbin
spec:
ports:
- name: http
port: 8000
targetPort: 80
selector:
app: httpbin
Reminders
Extra node label is an advanced feature and requires you to make sure that the label exists during value input. If a wrong label is entered, the number of nodes in the TKE tunnel will become 0.
If the selector of the service and the extra node label have the same key, the configuration in the selector will prevail.
If the service port is modified (for example, from 80 to 8080), the change needs to be synced to API Gateway. If the service port is not modified while only the target port is modified, the change will be automatically synced to API Gateway.
Was this page helpful?