1
1
# Enhancement Proposal-928: Control Plane Dynamic Configuration
2
2
3
3
- Issue: https://github.com/nginxinc/nginx-kubernetes-gateway/issues/928
4
- - Status: Provisional
4
+ - Status: Implementable
5
5
6
6
## Summary
7
7
@@ -17,3 +17,86 @@ option that we will support is log level.
17
17
## Non-Goals
18
18
19
19
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