Skip to content

Commit 4070520

Browse files
committed
Enhancement Proposal (Implementable): NKG config
Update enhancement proposal with implementable details for NKG control plane dynamic configuration.
1 parent de1a135 commit 4070520

File tree

1 file changed

+84
-1
lines changed

1 file changed

+84
-1
lines changed

docs/proposals/control-plane-config.md

Lines changed: 84 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
# Enhancement Proposal-928: Control Plane Dynamic Configuration
22

33
- Issue: https://github.com/nginxinc/nginx-kubernetes-gateway/issues/928
4-
- Status: Provisional
4+
- Status: Implementable
55

66
## Summary
77

@@ -17,3 +17,86 @@ option that we will support is log level.
1717
## Non-Goals
1818

1919
This proposal is *not* defining a way to dynamically configure the data plane.
20+
21+
## Introduction
22+
23+
The NKG control plane will evolve to have various user-configurable options. These could include, but are not
24+
limited to, log level, tracing, or metrics. For the best user experience, these options should be able to be
25+
changed at runtime, to avoid having to restart NKG. The first option that we will allow users to configure is the
26+
log level. The easiest and most intuitive way to implement a Kubernetes-native API is through a CRD.
27+
28+
## API, Customer Driven Interfaces, and User Experience
29+
30+
The API would be provided in a CRD. An authorized user would interact with this CRD using `kubectl` to `get`
31+
or `edit` the configuration.
32+
33+
Proposed configuration CRD example:
34+
35+
```yaml
36+
apiVersion: nginx.gateway.k8s.io/v1beta1
37+
kind: NGINXControlConfig
38+
metadata:
39+
name: nkg-config
40+
namespace: nginx-gateway
41+
spec:
42+
logLevel: info
43+
...
44+
```
45+
46+
- The CRD would be Namespace-scoped, living in the same Namespace as the controller that it applies to.
47+
- CRD is initialized and created when NKG is deployed
48+
- NKG references the name of this CRD via CLI arg, and only watches this CRD
49+
- If user deletes resource, NKG logs an error and creates an event. Last state is used until CRD is restored.
50+
51+
For discussion with team:
52+
53+
- API group name
54+
- kind name
55+
- default resource name
56+
57+
## Use Cases
58+
59+
The high level use case for dynamically changing settings in the NKG control plane is to allow users to alter
60+
behavior without the need for restarting NKG and experiencing downtime.
61+
62+
For the specific log level use case, users may be experiencing problems with NKG that require more information to
63+
diagnose. These problems could include:
64+
65+
- Not seeing or processing Kubernetes resources that it should be.
66+
- Configuring the data plane incorrectly based on the defined Kubernetes resources.
67+
- Crashes or errors without enough detail.
68+
69+
Being able to dynamically change the log level can allow for a quick way to obtain more information about
70+
the state of the control plane without losing that state due to a required restart.
71+
72+
## Testing
73+
74+
Unit tests can be leveraged for verifying that NKG properly watches and acts on CRD changes. These tests would
75+
be similar in behavior as the current unit tests that verify Gateway API resource processing.
76+
77+
## Security Considerations
78+
79+
We need to ensure that any configurable fields that are exposed to a user are:
80+
81+
- Properly validated. This means that the fields should be the correct type (integer, string, etc.), have appropriate
82+
length, and use regex patterns or enums to prevent any unwanted input.
83+
- Have a valid use case. The more fields we expose, the more attack vectors we create. We should only be exposing
84+
fields that are genuinely useful for a user to change dynamically.
85+
86+
RBAC via the Kubernetes API server will ensure that only authorized users can update the CRD containing NKG control
87+
plane configuration.
88+
89+
## Alternatives
90+
91+
- ConfigMap
92+
A ConfigMap is another type of resource that a user can provide configuration options within, however it lacks the
93+
benefits of a CRD, specifically built-in schema validation, versioning, and conversion webhooks.
94+
95+
- Custom API server
96+
The NKG control plane could implement its own custom API server. However the overhead of implementing this, which
97+
would include auth, validation, endpoints, and so on, would not be worth it due to the fact that the Kubernetes
98+
API server already does all of these things for us.
99+
100+
## References
101+
102+
- [Kubernetes Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)

0 commit comments

Comments
 (0)