You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update Helm chart to include pod mutating webhook for readiness gates (#612)
Update Helm chart to include pod mutating webhook for readiness gates.
Moved webhook certificate provisioning out of build.
Added helper scripts and env variable for enabling webhooks and working with certificates
Copy file name to clipboardExpand all lines: docs/guides/pod-readiness-gates.md
+36-44Lines changed: 36 additions & 44 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,53 +18,45 @@ This prevents the rolling update of a deployment from terminating old pods until
18
18
## Setup
19
19
Pod readiness gates rely on [»admission webhooks«](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), where the Kubernetes API server makes calls to the AWS Gateway API controller as part of pod creation. This call is made using TLS, so the controller must present a TLS certificate. This certificate is stored as a standard Kubernetes secret. If you are using Helm, the certificate will automatically be configured as part of the Helm install.
20
20
21
-
If you are manually deploying the controller, for example using the ```deploy.yaml``` file, you will need to create the tls secret for the webhook in the controller namespace. The ```deploy.yaml``` file includes a placeholder secret, but it must be updated if you wish to use the webhook. The placeholder secret _will not_ pass API server validations, but will ensure the controller container is able to start.
21
+
If you are manually deploying the controllerusing the ```deploy.yaml``` file, you will need to either patch the ```deploy.yaml``` file (see ```scripts/patch-deploy-yaml.sh```) or generate the secret following installation (see ```scripts/gen-webhook-secret.sh```) and manually enable the webhook via the ```WEBHOOK_ENABLED``` environment variable.
22
22
23
-
### Webhook secret requirements
24
-
The webhook requires a specific kubernetes secret to exist in the same namespace as the webhook itself:
Note that, without the secret in place, the controller cannot start successfully, and you will see an error message like the following:
31
24
```
32
-
33
-
### Webhook secret configuration example
34
-
The below example creates an unsigned certificate, adds it as the webhook secret, then patches the webhook configuration so the API server trusts the certificate.
35
-
36
-
If your cluster uses its own PKI and includes appropriate trust configuration for the API server, the certificate issued would be signed by your internal certificate authority and therefore not require the ```kubectl patch``` command below.
37
-
```console
38
-
# Example commands to configure the webhook to use an unsigned certificate
{"level":"error","ts":"...","logger":"setup","caller":"workspace/main.go:240","msg":"tls: failed to find any PEM data in certificate inputproblem running manager"}
26
+
```
27
+
For this reason, the webhook is ```DISABLED``` by default in the controller for the non-Helm install. You can enable the webhook by setting the ```WEBHOOK_ENABLED``` environment variable to "true" in the ```deploy.yaml``` file.
28
+
```yaml
29
+
apiVersion: apps/v1
30
+
kind: Deployment
31
+
metadata:
32
+
name: gateway-api-controller
33
+
namespace: aws-application-networking-system
34
+
labels:
35
+
control-plane: gateway-api-controller
36
+
spec:
37
+
...
38
+
template:
39
+
metadata:
40
+
annotations:
41
+
kubectl.kubernetes.io/default-container: manager
42
+
labels:
43
+
control-plane: gateway-api-controller
44
+
spec:
45
+
securityContext:
46
+
runAsNonRoot: true
47
+
containers:
48
+
- command:
49
+
...
50
+
name: manager
51
+
...
52
+
env:
53
+
- name: WEBHOOK_ENABLED
54
+
value: "true"# <-- value of "true" enables the webhook in the controller
64
55
```
56
+
If you run ```scripts/patch-deploy-yaml.sh``` prior to installing ```deploy.yaml```, the script will create the necessary TLS certificates and configuration and will enable the webhook in the controller. Note that, even with the webhook enabled, the webhook will only run for namespaces labeled with `application-networking.k8s.aws/pod-readiness-gate-inject: enabled`.
65
57
66
-
## Configuration
67
-
Pod readiness gate support is enabled by default on the AWS Gateway API controller. To enable the feature, you must apply a label to each of the namespaces you would like to use this feature. You can create and label a namespace as follows -
58
+
## Enabling the readiness gate
59
+
After a Helm install or manually configuring and enabling the webhook, you are ready to begin using pod readiness gates. Apply a label to each namespace you would like to use this feature. You can create and label a namespace as follows -
68
60
69
61
```
70
62
$ kubectl create namespace example-ns
@@ -81,7 +73,7 @@ Annotations: <none>
81
73
Status: Active
82
74
```
83
75
84
-
Once labelled, the controller will add the pod readiness gates to all subsequently created pods.
76
+
Once labelled, the controller will add the pod readiness gates to all subsequently created pods in the namespace.
85
77
86
78
The readiness gates have the condition type ```application-networking.k8s.aws/pod-readiness-gate``` and the controller injects the config to the pod spec only during pod creation.
0 commit comments