GrpcBackendGroup resource fields
GrpcBackendGroup
enables you to combine Kubernetes service backends processing gRPC traffic into a group. The Application Load Balancer Ingress controller uses these resources to create backend groups.
You need to add a reference to GrpcBackendGroup
to the Ingress
resource. This Ingress
resource must have the ingress.alb.yc.io/protocol: grpc
annotation.
Example
---
apiVersion: alb.yc.io/v1alpha1
kind: GrpcBackendGroup
metadata:
namespace: testapp-ns
name: grpc-bg
spec:
backends:
- name: ying
weight: 50
service:
name: grpc-testapp-service
port:
number: 8080
- name: yang
weight: 50
service:
name: grpc-testapp-service2
port:
number: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: testapp-ingress-with-grpc-bg
namespace: testapp-ns
annotations:
ingress.alb.yc.io/group-name: default
ingress.alb.yc.io/protocol: grpc
spec:
rules:
- host: grpc-first-server.info
http:
paths:
- path: /helloworld.Greeter/SayHello
pathType: Prefix
backend:
resource:
apiGroup: alb.yc.io
kind: GrpcBackendGroup
name: grpc-bg
GrpcBackendGroup
is a custom resourcealb.yc.io
API group provided by an Ingress controller.
GrpcBackendGroup
apiVersion: alb.yc.io/v1alpha1
kind: GrpcBackendGroup
metadata:
name: <string>
spec:
backends:
- name: <string>
weight: <int64>
service:
name: <int64>
port:
name: <string>
number: <int32>
tls:
sni: <string>
trustedCa: <string>
healthChecks:
- grpc:
serviceName: <string>
port: <int32>
healthyThreshold: <int32>
unhealthyThreshold: <int32>
timeout: <string>
interval: <string>
- ...
Where:
-
apiVersion
:alb.yc.io/v1alpha1
-
kind
:GrpcBackendGroup
-
metadata
(ObjectMeta
, required)Resource metadata.
-
name
(string
, required)Resource name. For more information about the name format, see the relevant Kubernetes guides
.You must specify this name in the
spec.rules.http.paths.backend.resource.name
field of theIngress
resource. For more information, see the relevant configuration.Do not mistake this name for the Application Load Balancer backend group name.
-
-
spec
(GrpcBackendGroupSpec
)Resource specification.
-
backends
([]GrpcBackend
)List of the group backends.
-
name
(string
, required)Backend name.
-
weight
(int64
)Backend weight. Backends in a group receive traffic in proportion to their weights.
You should either specify weights for all backends in a group, or not specify them at all. If weights are not specified, traffic will be equally distributed between backends.
A backend with zero or negative weight will not be receiving traffic.
-
service
(ServiceBackend
)Kubernetes service backend for processing requests.
The referred
Service
resource must be described per the standard configuration.-
name
(string
, required):Kubernetes service name.
-
port
(ServiceBackendPort
, required):Service port to which
Ingress
will direct traffic.The field is designed for ingress controller operation and has no equivalents in Application Load Balancer.
-
name
(string
):Service port name.
This name must match one of the
Service
resourcespec.ports.name
values. For more information, see the resource specification.You must specify either the service port name or its
number
, but not both. -
number
(int32
):Service port number.
This number must match one of the
Service
resourcespec.ports.port
values. For more information, see the resource specification.You must specify either the service port
name
or its number, but not both.
-
-
-
tls
(BackendTLS
)TLS connection settings for the load balancer nodes and backend endpoints.
If this field is specified, the load balancer will establish TLS connections to the backend, comparing received certificates with the one specified in the
trustedCa
field. Otherwise, the load balancer will use unencrypted connections to the backend.-
sni
(string
)SNI domain name for TLS connections.
-
trustedCa
(string
)X.509 certificate in PEM format.
-
-
healthChecks
([]HealthChecks
)Custom health checks settings for Managed Service for Kubernetes cluster applications.
By default, the Application Load Balancer Ingress controller receives L7 load balancer health check requests on TCP port
10501
. Then it checks kube-proxy pods on each cluster node. Given that kube-proxy is healthy, the process is as follows: if an application does not respond in a particular pod, Kubernetes will redirect traffic to a different pod or node.You can use
healthChecks
settings to customize application health checks.-
grpc
(GrpcBackend
)Specifies gRPC as the health check protocol.
-
serviceName
(string
)Name of the service you want to check.
-
-
port
(int32
)Cluster node port for checking application availability. This port should match the
spec.ports.nodePort
value of theNodePort
Service resource.The application will listen for health check requests on
http://<node_IP_address>:<port>/<path>
. -
healthyThreshold
(int32
)Number of consecutive successful checks required before considering the application endpoint healthy.
-
unhealthyThreshold
(int32
)Number of consecutive failed checks required before considering the application endpoint unhealthy.
-
timeout
(string
)Response timeout in seconds. You can specify values between
1s
and60s
. -
interval
(string
)Health check request interval in seconds.
You can specify values between
1s
and60s
.interval
must exceedtimeout
by at least one second.
Note
You can also configure application health checks using the ingress.alb.yc.io/health-checks annotation of the Service resource.
-
-
-