@@ -105,28 +105,32 @@ type Handler struct {
105
105
// ...
106
106
TCPSocket *TCPSocketAction ` json...`
107
107
108
- // GRPC specifies an action involving a TCP port. //+
109
- // +optional //+
110
- GRPC *GRPCAction `json...` //+
108
+ // GRPC specifies an action involving a TCP port. //+
109
+ // +optional //+
110
+ GRPC *GRPCAction `json...` //+
111
111
112
112
// ...
113
113
}
114
114
115
- type GRPCAction struct {
116
- // Port number of the gRPC service. Number must be in the range 1 to 65535.
117
- Port int `json:"port" protobuf:"bytes,1,opt,name=port"`
118
-
119
- // Service is the name of the service to place in the gRPC HealthCheckRequest
120
- // (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md).
121
- //
122
- // The service name can be the empty string (i.e. "").
123
- Service string `json:"service" protobuf:"bytes,2,opt,name=service"`
124
-
125
- // Host is the host name to connect to, defaults to the Pod's IP.
126
- Host string `json,omitempty", protobuf:"bytes,3,opt,name=host"`
127
- }
115
+ type GRPCAction struct { //+
116
+ // Port number of the gRPC service. Number must be in the range 1 to 65535. //+
117
+ Port int32 `json:"port" protobuf:"bytes,1,opt,name=port"` //+
118
+ //+
119
+ // Service is the name of the service to place in the gRPC HealthCheckRequest //+
120
+ // (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md). //+
121
+ // //+
122
+ // The service name can be the empty string (i.e. ""). //+
123
+ Service string `json:"service" protobuf:"bytes,2,opt,name=service"` //+
124
+ //+
125
+ // Host is the host name to connect to, defaults to the Pod's IP. //+
126
+ Host string `json,omitempty", protobuf:"bytes,3,opt,name=host"` //+
127
+ } //+
128
128
```
129
129
130
+ Note that ` GRPCAction.Port ` is an int32, which is inconsistent with
131
+ the other existing probe definitions. This is on purpose -- we want to
132
+ move users away from using the (portNum, portName) union type.
133
+
130
134
### Test Plan
131
135
132
136
- Unit test: Add unit tests to ` pkg/kubelet/prober/... `
@@ -206,23 +210,27 @@ Pick one of these and delete the rest.
206
210
207
211
- [x] Feature gate (also fill in values in ` kep.yaml ` )
208
212
- Feature gate name: ` GRPCContainerProbe `
209
- - Components depending on the feature gate: ` kubelet `
213
+ - Components depending on the feature gate: ` kubelet ` (probing), API
214
+ server (API changes).
210
215
211
216
###### Does enabling the feature change any default behavior?
212
217
213
218
No.
214
219
215
220
###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
216
221
217
- Yes.
222
+ Yes. This would require restarting kubelet, and so probes for existing
223
+ Pods would no longer run.
218
224
219
225
###### What happens if we reenable the feature if it was previously rolled back?
220
226
221
- It becomes enabled.
227
+ It becomes enabled again after the ` kubelet ` restart .
222
228
223
229
###### Are there any tests for feature enablement/disablement?
224
230
225
- No, alpha.
231
+ Y
232
+ es, unit tests for the feature when enabled and disabled will be
233
+ implemented in both kubelet and api server.
226
234
227
235
### Rollout, Upgrade and Rollback Planning
228
236
@@ -291,10 +299,10 @@ Recall that end users cannot usually observe component logs or access metrics.
291
299
->
292
300
293
301
- [ ] Events
294
- - Event Reason:
302
+ - Event Reason:
295
303
- [ ] API .status
296
- - Condition name:
297
- - Other field:
304
+ - Condition name:
305
+ - Other field:
298
306
- [ ] Other (treat as last resort)
299
307
- Details:
300
308
@@ -437,6 +445,7 @@ Major milestones might include:
437
445
* Original PR for k8 Prober: https://github.com/kubernetes/kubernetes/pull/89832
438
446
* 2020-04-04: MR for k8 Prober
439
447
* 2021-05-12: Cloned to this KEP to move the probe forward.
448
+ * 2021-05-13: Updates.
440
449
441
450
## Alternatives
442
451
0 commit comments