Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/main' into kustomize_helm_grafana
Browse files Browse the repository at this point in the history
Signed-off-by: Chris Blumentritt <[email protected]>
  • Loading branch information
cblument committed Mar 20, 2024
2 parents 6b55c7e + 70c7f26 commit 7e2f27a
Show file tree
Hide file tree
Showing 6 changed files with 243 additions and 0 deletions.
3 changes: 3 additions & 0 deletions .gitmodules
Original file line number Diff line number Diff line change
Expand Up @@ -13,3 +13,6 @@
[submodule "submodules/openstack-exporter"]
path = submodules/openstack-exporter
url = https://github.com/openstack-exporter/helm-charts
[submodule "submodules/nginx-gateway-fabric"]
path = submodules/nginx-gateway-fabric
url = https://github.com/nginxinc/nginx-gateway-fabric.git
Binary file added docs/assets/images/flexingress.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
121 changes: 121 additions & 0 deletions docs/infrastructure-gateway-api.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
## Gateway API

Gateway API is L4 and L7 layer routing project in Kubernetes. It represents next generation of k8s Ingress, LB and Service Mesh APIs. For more information on the project see: [Gateway API SIG.](https://gateway-api.sigs.k8s.io/)

**Move from Ingress to Gateway APIs**
Since Gateway APIs are successor to Ingress Controllers there needs to be a one time migration from Ingress -> GW API resources. To learn more about it refer to: [Ingress Migration](https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/#migrating-from-ingress)


### Resource Models in Gateway API
There are 3 main resource models in gateway apis:
1. GatewayClass - Mostly managed by a controller.
2. Gateway - An instance of traffic handling infra like a LB.
3. Routes - Defines HTTP-specific rules for mapping traffic from a Gateway listener to a representation of backend network endpoints.

**k8s Gateway API is NOT the same as API Gateways**
While both sound the same, API Gateway is a more of a general concept that defines a set of resources that exposes capabilities of a backend service but also provide other functionalities like traffic management, rate limiting, authentication and more. It is geared towards commercial API management and monetisation.

From the gateway api sig:

!!! note

Most Gateway API implementations are API Gateways to some extent, but not all API Gateways are Gateway API implementations.


### Controller: NGINX Gateway Fabric
[NGINX Gateway Fabric](https://github.com/nginxinc/nginx-gateway-fabric) is an open-source project that provides an implementation of the Gateway API using nginx as the data plane.

Chart Install: https://github.com/nginxinc/nginx-gateway-fabric/blob/main/deploy/helm-chart/values.yaml

Create the Namespace
```
kubectl create ns nginx-gateway
```

First Install the Gateway API Resource from Kubernetes
```
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml
```

Next, Install the NGINX Gateway Fabric controller
```
cd /opt/genestack/submodules/nginx-gateway-fabric
helm upgrade --install nginx-gateway-fabric . --namespace=nginx-gateway -f /opt/genestack/helm-configs/nginx-gateway-fabric/helm-overrides.yaml
```

Helm install does not automatically upgrade the crds for this resource. To upgrade the crds you will have to manually install them. Follow the process from : [Upgrade CRDs](https://docs.nginx.com/nginx-gateway-fabric/installation/installing-ngf/helm/#upgrade-nginx-gateway-fabric-crds)

### Example Implementation with Prometheus UI

In this example we will look at how Prometheus UI is exposed through the gateway. For other services the gateway kustomization file for the service.

First, create the shared gateway and then the httproute resource for prometheus.
```
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: flex-gateway
spec:
gatewayClassName: nginx
listeners:
- name: http
port: 80
protocol: HTTP
hostname: "*.sjc.ohthree.com"
```

then

```
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: prometheus-gateway-route
spec:
parentRefs:
- name: flex-gateway
sectionName: http
hostnames:
- "prometheus.sjc.ohthree.com"
rules:
- backendRefs:
- name: kube-prometheus-stack-prometheus
port: 9090
```
At this point, flex-gateway has a listener pointed to the port 80 matching *.sjc.ohthree.com hostname. The HTTPRoute resource configures routes for this gateway. Here, we match all path and simply pass any request from the matching hostname to kube-prometheus-stack-prometheus backend service.

### Exposing Flex Services

We have a requirement to expose a service

1. Internally for private consumption (Management and Administrative Services)
2. Externally to customers (mostly Openstack services)

![Flex Service Expose External with F5 Loadbalancer](assets/images/flexingress.png)

For each externally exposed service, example: keystone endpoint, we have a GatewayAPI resource setup to use listeners on services with matching rules based on hostname, for example keystone.sjc.api.rackspacecloud.com. When a request comes in to the f5 vip for this the vip is setup to pass the traffic to the Metallb external vip address. Metallb then forwards the traffic to the appropriate service endpoint for the gateway controller which matches the hostname and passes the traffic onto the right service. The same applies to internal services. Anything that matches ohthree.com hostname can be considered internal and handled accordingly.

```
External Traffic -> F5 VIP Address -> MetalLB VIP Address -> Gateway Service
```

This setup can be expended to have multiple MetalLB VIPs with multiple Gateway Services listening on different IP addresses as required by your setup.

!!! tip

The metalLB speaker wont advertise the service if :

1. There is no active endpoint backing the service

2. There are no matching L2 or BGP speaker nodes

3. If the service has external Traffic Policy set to local you need to have the running endpoint on the speaker node.


### Cross Namespace Routing

Gateway API has support for multi-ns and cross namespace routing. Routes can be deployed into different Namespaces and Routes can attach to Gateways across Namespace boundaries. This allows user access control to be applied differently across Namespaces for Routes and Gateways, effectively segmenting access and control to different parts of the cluster-wide routing configuration.

See: https://gateway-api.sigs.k8s.io/guides/multiple-ns/ for more information on cross namespace routing.
117 changes: 117 additions & 0 deletions helm-configs/nginx-gateway-fabric/helm-overrides.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
nginxGateway:
## The kind of the NGINX Gateway Fabric installation - currently, only deployment is supported.
kind: deployment
## gatewayClassName is the name of the GatewayClass that will be created as part of this release. Every NGINX Gateway
## Fabric must have a unique corresponding GatewayClass resource. NGINX Gateway Fabric only processes resources that
## belong to its class - i.e. have the "gatewayClassName" field resource equal to the class.
gatewayClassName: nginx
## The name of the Gateway controller. The controller name must be of the form: DOMAIN/PATH. The controller's domain
## is gateway.nginx.org.
gatewayControllerName: gateway.nginx.org/nginx-gateway-controller
## The dynamic configuration for the control plane that is contained in the NginxGateway resource.
config:
logging:
## Log level. Supported values "info", "debug", "error".
level: info
## The number of replicas of the NGINX Gateway Fabric Deployment.
replicaCount: 1
## The configuration for leader election.
leaderElection:
## Enable leader election. Leader election is used to avoid multiple replicas of the NGINX Gateway Fabric
## reporting the status of the Gateway API resources. If not enabled, all replicas of NGINX Gateway Fabric
## will update the statuses of the Gateway API resources.
enable: true
## The name of the leader election lock. A Lease object with this name will be created in the same Namespace as
## the controller. Autogenerated if not set or set to "".
lockName: ""

## Defines the settings for the control plane readiness probe. This probe returns Ready when the controller
## has started and configured NGINX to serve traffic.
readinessProbe:
## Enable the /readyz endpoint on the control plane.
enable: true
## Port in which the readiness endpoint is exposed.
port: 8081
## The number of seconds after the Pod has started before the readiness probes are initiated.
initialDelaySeconds: 3

image:
## The NGINX Gateway Fabric image to use
repository: ghcr.io/nginxinc/nginx-gateway-fabric
tag: 1.1.0
pullPolicy: IfNotPresent

securityContext:
## Some environments may need this set to true in order for the control plane to successfully reload NGINX.
allowPrivilegeEscalation: false

## The lifecycle of the nginx-gateway container.
lifecycle: {}

## extraVolumeMounts are the additional volume mounts for the nginx-gateway container.
extraVolumeMounts: []

nginx:
## The NGINX image to use
image:
repository: ghcr.io/nginxinc/nginx-gateway-fabric/nginx
tag: 1.1.0
pullPolicy: IfNotPresent

## The lifecycle of the nginx container.
lifecycle: {}

## extraVolumeMounts are the additional volume mounts for the nginx container.
extraVolumeMounts: []

## The termination grace period of the NGINX Gateway Fabric pod.
terminationGracePeriodSeconds: 30

## Tolerations for the NGINX Gateway Fabric pod.
tolerations: []

## The affinity of the NGINX Gateway Fabric pod.
affinity: {}

serviceAccount:
annotations: {}
## The name of the service account of the NGINX Gateway Fabric pods. Used for RBAC.
## Autogenerated if not set or set to "".
# name: nginx-gateway

service:
## Creates a service to expose the NGINX Gateway Fabric pods.
create: true
## The type of service to create for the NGINX Gateway Fabric.
type: LoadBalancer
## The externalTrafficPolicy of the service. The value Local preserves the client source IP.
externalTrafficPolicy: Local
## The annotations of the NGINX Gateway Fabric service.
annotations:
"metallb.universe.tf/address-pool": "openstack-external"
"metallb.universe.tf/allow-shared-ip": "openstack-external-svc"

## A list of ports to expose through the NGINX Gateway Fabric service. Update it to match the listener ports from
## your Gateway resource. Follows the conventional Kubernetes yaml syntax for service ports.
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https

metrics:
## Enable exposing metrics in the Prometheus format.
enable: true
## Set the port where the Prometheus metrics are exposed. Format: [1024 - 65535]
port: 9113
## Enable serving metrics via https. By default metrics are served via http.
## Please note that this endpoint will be secured with a self-signed certificate.
secure: false

## extraVolumes for the NGINX Gateway Fabric pod. Use in conjunction with
## nginxGateway.extraVolumeMounts and nginx.extraVolumeMounts to mount additional volumes to the containers.
extraVolumes: []
1 change: 1 addition & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -168,6 +168,7 @@ nav:
- infrastructure-ovn.md
- OVN Setup: infrastructure-ovn-setup.md
- MetalLB: infrastructure-metallb.md
- Gateway API: infrastructure-gateway-api.md
- Loki: infrastructure-loki.md
- OpenStack:
- openstack-overview.md
Expand Down
1 change: 1 addition & 0 deletions submodules/nginx-gateway-fabric
Submodule nginx-gateway-fabric added at 4e3d9c

0 comments on commit 7e2f27a

Please sign in to comment.