Skip to content

Commit 9626282

Browse files
committed
[zh] Sync extend-service-ip-ranges.md
1 parent b3e0ed2 commit 9626282

File tree

1 file changed

+116
-1
lines changed

1 file changed

+116
-1
lines changed

content/zh-cn/docs/tasks/network/extend-service-ip-ranges.md

+116-1
Original file line numberDiff line numberDiff line change
@@ -30,9 +30,19 @@ This document shares how to extend the existing Service IP range assigned to a c
3030

3131
{{< version-check >}}
3232

33+
{{< note >}}
34+
<!--
35+
While you can use this feature with an earlier version, the feature is only GA and officially supported since v1.33.
36+
-->
37+
虽然你可以在更早的版本中使用此特性,但此特性只有从 v1.33 版本开始才进阶至 GA(正式发布)并获得官方支持。
38+
{{< /note >}}
39+
3340
<!-- steps -->
3441

35-
## API
42+
<!--
43+
## Extend Service IP Ranges
44+
-->
45+
## 扩展 Service IP 范围 {#extend-service-ip-ranges}
3646

3747
<!--
3848
Kubernetes clusters with kube-apiservers that have enabled the `MultiCIDRServiceAllocator`
@@ -260,3 +270,108 @@ kubectl get servicecidr newcidr1
260270
```
261271
Error from server (NotFound): servicecidrs.networking.k8s.io "newcidr1" not found
262272
```
273+
274+
## Kubernetes Service CIDR Policies
275+
276+
Cluster administrators can implement policies to control the creation and
277+
modification of ServiceCIDR resources within the cluster. This allows for
278+
centralized management of the IP address ranges used for Services and helps
279+
prevent unintended or conflicting configurations. Kubernetes provides mechanisms
280+
like Validating Admission Policies to enforce these rules.
281+
282+
### Preventing Unauthorized ServiceCIDR Creation/Update using Validating Admission Policy
283+
284+
There can be situations that the cluster administrators want to restrict the
285+
ranges that can be allowed or to completely deny any changes to the cluster
286+
Service IP ranges.
287+
288+
{{< note >}}
289+
The default "kubernetes" ServiceCIDR is created by the kube-apiserver
290+
to provide consistency in the cluster and is required for the cluster to work,
291+
so it always must be allowed. You can ensure your `ValidatingAdmissionPolicy`
292+
doesn't restrict the default ServiceCIDR by adding the clause:
293+
294+
```yaml
295+
matchConditions:
296+
- name: 'exclude-default-servicecidr'
297+
expression: "object.metadata.name != 'kubernetes'"
298+
```
299+
300+
as in the examples below.
301+
{{</ note >}}
302+
303+
#### Restrict Service CIDR ranges to some specific ranges
304+
305+
The following is an example of a `ValidatingAdmissionPolicy` that only allows
306+
ServiceCIDRs to be created if they are subranges of the given `allowed` ranges.
307+
(So the example policy would allow a ServiceCIDR with `cidrs: ['10.96.1.0/24']`
308+
or `cidrs: ['2001:db8:0:0:ffff::/80', '10.96.0.0/20']` but would not allow a
309+
ServiceCIDR with `cidrs: ['172.20.0.0/16']`.) You can copy this policy and change
310+
the value of `allowed` to something appropriate for you cluster.
311+
312+
```yaml
313+
apiVersion: admissionregistration.k8s.io/v1
314+
kind: ValidatingAdmissionPolicy
315+
metadata:
316+
name: "servicecidrs.default"
317+
spec:
318+
failurePolicy: Fail
319+
matchConstraints:
320+
resourceRules:
321+
- apiGroups: ["networking.k8s.io"]
322+
apiVersions: ["v1","v1beta1"]
323+
operations: ["CREATE", "UPDATE"]
324+
resources: ["servicecidrs"]
325+
matchConditions:
326+
- name: 'exclude-default-servicecidr'
327+
expression: "object.metadata.name != 'kubernetes'"
328+
variables:
329+
- name: allowed
330+
expression: "['10.96.0.0/16','2001:db8::/64']"
331+
validations:
332+
- expression: "object.spec.cidrs.all(newCIDR, variables.allowed.exists(allowedCIDR, cidr(allowedCIDR).containsCIDR(newCIDR)))"
333+
# For all CIDRs (newCIDR) listed in the spec.cidrs of the submitted ServiceCIDR
334+
# object, check if there exists at least one CIDR (allowedCIDR) in the `allowed`
335+
# list of the VAP such that the allowedCIDR fully contains the newCIDR.
336+
---
337+
apiVersion: admissionregistration.k8s.io/v1
338+
kind: ValidatingAdmissionPolicyBinding
339+
metadata:
340+
name: "servicecidrs-binding"
341+
spec:
342+
policyName: "servicecidrs.default"
343+
validationActions: [Deny,Audit]
344+
```
345+
346+
Consult the [CEL documentation](https://kubernetes.io/docs/reference/using-api/cel/)
347+
to learn more about CEL if you want to write your own validation `expression`.
348+
349+
#### Restrict any usage of the ServiceCIDR API
350+
351+
The following example demonstrates how to use a `ValidatingAdmissionPolicy` and
352+
its binding to restrict the creation of any new Service CIDR ranges, excluding the default "kubernetes" ServiceCIDR:
353+
354+
```yaml
355+
apiVersion: admissionregistration.k8s.io/v1
356+
kind: ValidatingAdmissionPolicy
357+
metadata:
358+
name: "servicecidrs.deny"
359+
spec:
360+
failurePolicy: Fail
361+
matchConstraints:
362+
resourceRules:
363+
- apiGroups: ["networking.k8s.io"]
364+
apiVersions: ["v1","v1beta1"]
365+
operations: ["CREATE", "UPDATE"]
366+
resources: ["servicecidrs"]
367+
validations:
368+
- expression: "object.metadata.name == 'kubernetes'"
369+
---
370+
apiVersion: admissionregistration.k8s.io/v1
371+
kind: ValidatingAdmissionPolicyBinding
372+
metadata:
373+
name: "servicecidrs-deny-binding"
374+
spec:
375+
policyName: "servicecidrs.deny"
376+
validationActions: [Deny,Audit]
377+
```

0 commit comments

Comments
 (0)