Merge remote-tracking branch 'upstream/main' into dev-1.25
This commit is contained in:
Seth McCombs
@@ -0,0 +1,178 @@
|
||||
---
|
||||
layout: blog
|
||||
title: Kubernetes Gateway API Graduates to Beta
|
||||
date: 2022-07-13
|
||||
slug: gateway-api-graduates-to-beta
|
||||
canonicalUrl: https://gateway-api.sigs.k8s.io/blog/2022/graduating-to-beta/
|
||||
---
|
||||
|
||||
**Authors:** Shane Utt (Kong), Rob Scott (Google), Nick Young (VMware), Jeff Apple (HashiCorp)
|
||||
|
||||
We are excited to announce the v0.5.0 release of Gateway API. For the first
|
||||
time, several of our most important Gateway API resources are graduating to
|
||||
beta. Additionally, we are starting a new initiative to explore how Gateway API
|
||||
can be used for mesh and introducing new experimental concepts such as URL
|
||||
rewrites. We'll cover all of this and more below.
|
||||
|
||||
## What is Gateway API?
|
||||
|
||||
Gateway API is a collection of resources centered around [Gateway][gw] resources
|
||||
(which represent the underlying network gateways / proxy servers) to enable
|
||||
robust Kubernetes service networking through expressive, extensible and
|
||||
role-oriented interfaces that are implemented by many vendors and have broad
|
||||
industry support.
|
||||
|
||||
Originally conceived as a successor to the well known [Ingress][ing] API, the
|
||||
benefits of Gateway API include (but are not limited to) explicit support for
|
||||
many commonly used networking protocols (e.g. `HTTP`, `TLS`, `TCP`, `UDP`) as
|
||||
well as tightly integrated support for Transport Layer Security (TLS). The
|
||||
`Gateway` resource in particular enables implementations to manage the lifecycle
|
||||
of network gateways as a Kubernetes API.
|
||||
|
||||
If you're an end-user interested in some of the benefits of Gateway API we
|
||||
invite you to jump in and find an implementation that suits you. At the time of
|
||||
this release there are over a dozen [implementations][impl] for popular API
|
||||
gateways and service meshes and guides are available to start exploring quickly.
|
||||
|
||||
[gw]:https://gateway-api.sigs.k8s.io/api-types/gateway/
|
||||
[ing]:https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/
|
||||
[impl]:https://gateway-api.sigs.k8s.io/implementations/
|
||||
|
||||
### Getting started
|
||||
|
||||
Gateway API is an official Kubernetes API like
|
||||
[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
|
||||
Gateway API represents a superset of Ingress functionality, enabling more
|
||||
advanced concepts. Similar to Ingress, there is no default implementation of
|
||||
Gateway API built into Kubernetes. Instead, there are many different
|
||||
[implementations][impl] available, providing significant choice in terms of underlying
|
||||
technologies while providing a consistent and portable experience.
|
||||
|
||||
Take a look at the [API concepts documentation][concepts] and check out some of
|
||||
the [Guides][guides] to start familiarizing yourself with the APIs and how they
|
||||
work. When you're ready for a practical application open the [implementations
|
||||
page][impl] and select an implementation that belongs to an existing technology
|
||||
you may already be familiar with or the one your cluster provider uses as a
|
||||
default (if applicable). Gateway API is a [Custom Resource Definition
|
||||
(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto a
|
||||
cluster to use the API.
|
||||
|
||||
If you're specifically interested in helping to contribute to Gateway API, we
|
||||
would love to have you! Please feel free to [open a new issue][issue] on the
|
||||
repository, or join in the [discussions][disc]. Also check out the [community
|
||||
page][community] which includes links to the Slack channel and community meetings.
|
||||
|
||||
[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
|
||||
[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
|
||||
[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
|
||||
[impl]:https://gateway-api.sigs.k8s.io/implementations/
|
||||
[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
|
||||
[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
|
||||
[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
|
||||
[community]:https://gateway-api.sigs.k8s.io/contributing/community/
|
||||
|
||||
## Release highlights
|
||||
|
||||
### Graduation to beta
|
||||
|
||||
The `v0.5.0` release is particularly historic because it marks the growth in
|
||||
maturity to a beta API version (`v1beta1`) release for some of the key APIs:
|
||||
|
||||
- [GatewayClass](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/)
|
||||
- [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/)
|
||||
- [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/)
|
||||
|
||||
This achievement was marked by the completion of several graduation criteria:
|
||||
|
||||
- API has been [widely implemented][impl].
|
||||
- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests.
|
||||
- Most of the API surface is actively being used.
|
||||
- Kubernetes SIG Network API reviewers have approved graduation to beta.
|
||||
|
||||
For more information on Gateway API versioning, refer to the [official
|
||||
documentation](https://gateway-api.sigs.k8s.io/concepts/versioning/). To see
|
||||
what's in store for future releases check out the [next steps](#next-steps)
|
||||
section.
|
||||
|
||||
[impl]:https://gateway-api.sigs.k8s.io/implementations/
|
||||
|
||||
### Release channels
|
||||
|
||||
This release introduces the `experimental` and `standard` [release channels][ch]
|
||||
which enable a better balance of maintaining stability while still enabling
|
||||
experimentation and iterative development.
|
||||
|
||||
The `standard` release channel includes:
|
||||
|
||||
- resources that have graduated to beta
|
||||
- fields that have graduated to standard (no longer considered experimental)
|
||||
|
||||
The `experimental` release channel includes everything in the `standard` release
|
||||
channel, plus:
|
||||
|
||||
- `alpha` API resources
|
||||
- fields that are considered experimental and have not graduated to `standard` channel
|
||||
|
||||
Release channels are used internally to enable iterative development with
|
||||
quick turnaround, and externally to indicate feature stability to implementors
|
||||
and end-users.
|
||||
|
||||
For this release we've added the following experimental features:
|
||||
|
||||
- [Routes can attach to Gateways by specifying port numbers](https://gateway-api.sigs.k8s.io/geps/gep-957/)
|
||||
- [URL rewrites and path redirects](https://gateway-api.sigs.k8s.io/geps/gep-726/)
|
||||
|
||||
[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard
|
||||
|
||||
### Other improvements
|
||||
|
||||
For an exhaustive list of changes included in the `v0.5.0` release, please see
|
||||
the [v0.5.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0).
|
||||
|
||||
## Gateway API for service mesh: the GAMMA Initiative
|
||||
Some service mesh projects have [already implemented support for the Gateway
|
||||
API](https://gateway-api.sigs.k8s.io/implementations/). Significant overlap
|
||||
between the Service Mesh Interface (SMI) APIs and the Gateway API has [inspired
|
||||
discussion in the SMI
|
||||
community](https://github.com/servicemeshinterface/smi-spec/issues/249) about
|
||||
possible integration.
|
||||
|
||||
We are pleased to announce that the service mesh community, including
|
||||
representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX
|
||||
Service Mesh and Open Service Mesh, is coming together to form the [GAMMA
|
||||
Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/), a dedicated
|
||||
workstream within the Gateway API subproject focused on Gateway API for Mesh
|
||||
Management and Administration.
|
||||
|
||||
This group will deliver [enhancement
|
||||
proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting
|
||||
of resources, additions, and modifications to the Gateway API specification for
|
||||
mesh and mesh-adjacent use-cases.
|
||||
|
||||
This work has begun with [an exploration of using Gateway API for
|
||||
service-to-service
|
||||
traffic](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5)
|
||||
and will continue with enhancement in areas such as authentication and
|
||||
authorization policy.
|
||||
|
||||
## Next steps
|
||||
|
||||
As we continue to mature the API for production use cases, here are some of the highlights of what we'll be working on for the next Gateway API releases:
|
||||
|
||||
- [GRPCRoute][gep1016] for [gRPC][grpc] traffic routing
|
||||
- [Route delegation][pr1085]
|
||||
- Layer 4 API maturity: Graduating [TCPRoute][tcpr], [UDPRoute][udpr] and
|
||||
[TLSRoute][tlsr] to beta
|
||||
- [GAMMA Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/) - Gateway API for Service Mesh
|
||||
|
||||
If there's something on this list you want to get involved in, or there's
|
||||
something not on this list that you want to advocate for to get on the roadmap
|
||||
please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly [community calls](https://gateway-api.sigs.k8s.io/contributing/community/#meetings).
|
||||
|
||||
[gep1016]:https://github.com/kubernetes-sigs/gateway-api/blob/master/site-src/geps/gep-1016.md
|
||||
[grpc]:https://grpc.io/
|
||||
[pr1085]:https://github.com/kubernetes-sigs/gateway-api/pull/1085
|
||||
[tcpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tcproute_types.go
|
||||
[udpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/udproute_types.go
|
||||
[tlsr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tlsroute_types.go
|
||||
[community]:https://gateway-api.sigs.k8s.io/contributing/community/
|
||||
@@ -332,7 +332,7 @@ container of a Pod can specify either or both of the following:
|
||||
|
||||
Limits and requests for `ephemeral-storage` are measured in byte quantities.
|
||||
You can express storage as a plain integer or as a fixed-point number using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following quantities all represent roughly the same value:
|
||||
|
||||
- `128974848`
|
||||
@@ -340,6 +340,10 @@ Mi, Ki. For example, the following quantities all represent roughly the same val
|
||||
- `129M`
|
||||
- `123Mi`
|
||||
|
||||
Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request
|
||||
for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
|
||||
or 400 megabytes (`400M`).
|
||||
|
||||
In the following example, the Pod has two containers. Each container has a request of
|
||||
2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral
|
||||
storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and
|
||||
|
||||
@@ -85,11 +85,15 @@ The kubelet supports the following filesystem partitions:
|
||||
Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet
|
||||
does not support other configurations.
|
||||
|
||||
{{<note>}}
|
||||
Some kubelet garbage collection features are deprecated in favor of eviction.
|
||||
For a list of the deprecated features, see
|
||||
[kubelet garbage collection deprecation](/docs/concepts/architecture/garbage-collection/#deprecation).
|
||||
{{</note>}}
|
||||
Some kubelet garbage collection features are deprecated in favor of eviction:
|
||||
|
||||
| Existing Flag | New Flag | Rationale |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
|
||||
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
|
||||
|
||||
### Eviction thresholds
|
||||
|
||||
|
||||
@@ -558,7 +558,7 @@ If the access modes are specified as ReadWriteOncePod, the volume is constrained
|
||||
| AzureFile | ✓ | ✓ | ✓ | - |
|
||||
| AzureDisk | ✓ | - | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ | - |
|
||||
| Cinder | ✓ | - | - | - |
|
||||
| Cinder | ✓ | - | ([if multi-attach volumes are available](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes)) | - |
|
||||
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
|
||||
| FC | ✓ | ✓ | - | - |
|
||||
| FlexVolume | ✓ | ✓ | depends on the driver | - |
|
||||
|
||||
@@ -73,7 +73,7 @@ volume mount will not receive updates for those volume sources.
|
||||
|
||||
## SecurityContext interactions
|
||||
|
||||
The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set.
|
||||
The [proposal](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the correct owner permissions set.
|
||||
|
||||
### Linux
|
||||
|
||||
@@ -99,6 +99,7 @@ into their own volume mount outside of `C:\`.
|
||||
|
||||
By default, the projected files will have the following ownership as shown for
|
||||
an example projected volume file:
|
||||
|
||||
```powershell
|
||||
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
|
||||
|
||||
@@ -111,6 +112,7 @@ Access : NT AUTHORITY\SYSTEM Allow FullControl
|
||||
Audit :
|
||||
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
|
||||
```
|
||||
|
||||
This implies all administrator users like `ContainerAdministrator` will have
|
||||
read, write and execute access while, non-administrator users will have read and
|
||||
execute access.
|
||||
|
||||
@@ -132,7 +132,7 @@ section refers to several key workload abstractions and how they map to Windows.
|
||||
* CronJob
|
||||
* ReplicationController
|
||||
* {{< glossary_tooltip text="Services" term_id="service" >}}
|
||||
See [Load balancing and Services](#load-balancing-and-services) for more details.
|
||||
See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details.
|
||||
|
||||
Pods, workload resources, and Services are critical elements to managing Windows
|
||||
workloads on Kubernetes. However, on their own they are not enough to enable
|
||||
|
||||
@@ -71,7 +71,7 @@ Pod Template:
|
||||
job-name=pi
|
||||
Containers:
|
||||
pi:
|
||||
Image: perl
|
||||
Image: perl:5.34.0
|
||||
Port: <none>
|
||||
Host Port: <none>
|
||||
Command:
|
||||
@@ -125,7 +125,7 @@ spec:
|
||||
- -Mbignum=bpi
|
||||
- -wle
|
||||
- print bpi(2000)
|
||||
image: perl
|
||||
image: perl:5.34.0
|
||||
imagePullPolicy: Always
|
||||
name: pi
|
||||
resources: {}
|
||||
@@ -356,7 +356,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
image: perl:5.34.0
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
```
|
||||
@@ -402,7 +402,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
image: perl:5.34.0
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
@@ -216,16 +216,16 @@ Figure 2. Working from a local fork to make your changes.
|
||||
|
||||
1. Decide which branch base to your work on:
|
||||
|
||||
- For improvements to existing content, use `upstream/main`.
|
||||
- For new content about existing features, use `upstream/main`.
|
||||
- For localized content, use the localization's conventions. For more information, see
|
||||
[localizing Kubernetes documentation](/docs/contribute/localization/).
|
||||
- For new features in an upcoming Kubernetes release, use the feature branch. For more
|
||||
information, see [documenting for a release](/docs/contribute/new-content/new-features/).
|
||||
- For long-running efforts that multiple SIG Docs contributors collaborate on,
|
||||
like content reorganization, use a specific feature branch created for that effort.
|
||||
- For improvements to existing content, use `upstream/main`.
|
||||
- For new content about existing features, use `upstream/main`.
|
||||
- For localized content, use the localization's conventions. For more information, see
|
||||
[localizing Kubernetes documentation](/docs/contribute/localization/).
|
||||
- For new features in an upcoming Kubernetes release, use the feature branch. For more
|
||||
information, see [documenting for a release](/docs/contribute/new-content/new-features/).
|
||||
- For long-running efforts that multiple SIG Docs contributors collaborate on,
|
||||
like content reorganization, use a specific feature branch created for that effort.
|
||||
|
||||
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
|
||||
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
|
||||
|
||||
1. Create a new branch based on the branch identified in step 1. This example assumes the base
|
||||
branch is `upstream/main`:
|
||||
@@ -234,7 +234,7 @@ Figure 2. Working from a local fork to make your changes.
|
||||
git checkout -b <my_new_branch> upstream/main
|
||||
```
|
||||
|
||||
3. Make your changes using a text editor.
|
||||
1. Make your changes using a text editor.
|
||||
|
||||
At any time, use the `git status` command to see what files you've changed.
|
||||
|
||||
@@ -396,7 +396,7 @@ Figure 3. Steps to open a PR from your fork to the K8s/website.
|
||||
1. From the **head repository** drop-down menu, select your fork.
|
||||
1. From the **compare** drop-down menu, select your branch.
|
||||
1. Select **Create Pull Request**.
|
||||
`. Add a description for your pull request:
|
||||
1. Add a description for your pull request:
|
||||
|
||||
- **Title** (50 characters or less): Summarize the intent of the change.
|
||||
- **Description**: Describe the change in more detail.
|
||||
@@ -484,10 +484,10 @@ conflict. You must resolve all merge conflicts in your PR.
|
||||
|
||||
1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:
|
||||
|
||||
```shell
|
||||
git fetch upstream
|
||||
git rebase upstream/main
|
||||
```
|
||||
```shell
|
||||
git fetch upstream
|
||||
git rebase upstream/main
|
||||
```
|
||||
|
||||
1. Inspect the results of the rebase:
|
||||
|
||||
@@ -512,7 +512,7 @@ conflict. You must resolve all merge conflicts in your PR.
|
||||
|
||||
1. Continue the rebase:
|
||||
|
||||
``
|
||||
```shell
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
|
||||
@@ -10,9 +10,8 @@ weight: 10
|
||||
Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls)
|
||||
section in the Kubernetes website repository to see open pull requests.
|
||||
|
||||
Reviewing documentation pull requests is a
|
||||
great way to introduce yourself to the Kubernetes community.
|
||||
It helps you learn the code base and build trust with other contributors.
|
||||
Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes
|
||||
community. It helps you learn the code base and build trust with other contributors.
|
||||
|
||||
Before reviewing, it's a good idea to:
|
||||
|
||||
@@ -28,7 +27,6 @@ Before reviewing, it's a good idea to:
|
||||
|
||||
Before you start a review:
|
||||
|
||||
|
||||
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
|
||||
and ensure that you abide by it at all times.
|
||||
- Be polite, considerate, and helpful.
|
||||
@@ -73,6 +71,7 @@ class third,fourth white
|
||||
|
||||
Figure 1. Review process steps.
|
||||
|
||||
|
||||
1. Go to [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
|
||||
You see a list of every open pull request against the Kubernetes website and docs.
|
||||
|
||||
@@ -103,12 +102,20 @@ Figure 1. Review process steps.
|
||||
4. Go to the **Files changed** tab to start your review.
|
||||
|
||||
1. Click on the `+` symbol beside the line you want to comment on.
|
||||
1. Fill in any comments you have about the line and click either **Add single comment** (if you
|
||||
have only one comment to make) or **Start a review** (if you have multiple comments to make).
|
||||
1. Fill in any comments you have about the line and click either **Add single comment**
|
||||
(if you have only one comment to make) or **Start a review** (if you have multiple comments to make).
|
||||
1. When finished, click **Review changes** at the top of the page. Here, you can add
|
||||
a summary of your review (and leave some positive comments for the contributor!),
|
||||
approve the PR, comment or request changes as needed. New contributors should always
|
||||
choose **Comment**.
|
||||
a summary of your review (and leave some positive comments for the contributor!).
|
||||
Please always use the "Comment"
|
||||
|
||||
- Avoid clicking the "Request changes" button when finishing your review.
|
||||
If you want to block a PR from being merged before some further changes are made,
|
||||
you can leave a "/hold" comment.
|
||||
Mention why you are setting a hold, and optionally specify the conditions under
|
||||
which the hold can be removed by you or other reviewers.
|
||||
|
||||
- Avoid clicking the "Approve" button when finishing your review.
|
||||
Leaving a "/approve" comment is recommended most of the time.
|
||||
|
||||
## Reviewing checklist
|
||||
|
||||
|
||||
@@ -361,7 +361,7 @@ Beware.
|
||||
|
||||
### Katacoda Embedded Live Environment
|
||||
|
||||
This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel).
|
||||
This button lets users run Minikube in their browser using the Katacoda Terminal.
|
||||
It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete
|
||||
Minikube and Kubectl installation process locally.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 95
|
||||
|
||||
<!-- overview -->
|
||||
The tables below enumerate the configuration parameters on
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) objects, whether the field mutates
|
||||
[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects, whether the field mutates
|
||||
and/or validates pods, and how the configuration values map to the
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards/).
|
||||
|
||||
@@ -31,9 +31,9 @@ The fields enumerated in this table are part of the `PodSecurityPolicySpec`, whi
|
||||
under the `.spec` field path.
|
||||
|
||||
<table class="no-word-break">
|
||||
<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th><code>PodSecurityPolicySpec</code></th>
|
||||
<th>Type</th>
|
||||
<th>Pod Security Standards Equivalent</th>
|
||||
@@ -54,19 +54,19 @@ under the `.spec` field path.
|
||||
<td>
|
||||
<p><b>Baseline</b>: subset of</p>
|
||||
<ul>
|
||||
<li><code>AUDIT_WRITE</code></li>
|
||||
<li><code>CHOWN</code></li>
|
||||
<li><code>DAC_OVERRIDE</code></li>
|
||||
<li><code>FOWNER</code></li>
|
||||
<li><code>FSETID</code></li>
|
||||
<li><code>KILL</code></li>
|
||||
<li><code>MKNOD</code></li>
|
||||
<li><code>NET_BIND_SERVICE</code></li>
|
||||
<li><code>SETFCAP</code></li>
|
||||
<li><code>SETGID</code></li>
|
||||
<li><code>SETPCAP</code></li>
|
||||
<li><code>SETUID</code></li>
|
||||
<li><code>SYS_CHROOT</code></li>
|
||||
<li><code>AUDIT_WRITE</code></li>
|
||||
<li><code>CHOWN</code></li>
|
||||
<li><code>DAC_OVERRIDE</code></li>
|
||||
<li><code>FOWNER</code></li>
|
||||
<li><code>FSETID</code></li>
|
||||
<li><code>KILL</code></li>
|
||||
<li><code>MKNOD</code></li>
|
||||
<li><code>NET_BIND_SERVICE</code></li>
|
||||
<li><code>SETFCAP</code></li>
|
||||
<li><code>SETGID</code></li>
|
||||
<li><code>SETPCAP</code></li>
|
||||
<li><code>SETUID</code></li>
|
||||
<li><code>SYS_CHROOT</code></li>
|
||||
</ul>
|
||||
<p><b>Restricted</b>: empty / undefined / nil OR a list containing <i>only</i> <code>NET_BIND_SERVICE</code>
|
||||
</td>
|
||||
@@ -236,9 +236,9 @@ The [annotations](/docs/concepts/overview/working-with-objects/annotations/) enu
|
||||
table can be specified under `.metadata.annotations` on the PodSecurityPolicy object.
|
||||
|
||||
<table class="no-word-break">
|
||||
<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th><code>PSP Annotation</code></th>
|
||||
<th>Type</th>
|
||||
<th>Pod Security Standards Equivalent</th>
|
||||
|
||||
@@ -54,8 +54,8 @@ it can't be both.
|
||||
|
||||
ClusterRoles have several uses. You can use a ClusterRole to:
|
||||
|
||||
1. define permissions on namespaced resources and be granted within individual namespace(s)
|
||||
1. define permissions on namespaced resources and be granted across all namespaces
|
||||
1. define permissions on namespaced resources and be granted access within individual namespace(s)
|
||||
1. define permissions on namespaced resources and be granted access across all namespaces
|
||||
1. define permissions on cluster-scoped resources
|
||||
|
||||
If you want to define a role within a namespace, use a Role; if you want to define
|
||||
|
||||
@@ -90,7 +90,7 @@ kubelet [flags]
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--authorization-mode string Default: <code>AlwaysAllow</code></td></td>
|
||||
<td colspan="2">--authorization-mode string Default: <code>AlwaysAllow</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
|
||||
|
||||
@@ -2,9 +2,10 @@
|
||||
title: Extensions
|
||||
id: Extensions
|
||||
date: 2019-02-01
|
||||
full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
|
||||
full_link: /docs/concepts/extend-kubernetes/#extensions
|
||||
short_description: >
|
||||
Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.
|
||||
Extensions are software components that extend and deeply integrate with Kubernetes to support
|
||||
new types of hardware.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
@@ -15,4 +16,6 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters come with extensions pre-installed. As a result, most Kubernetes users will not need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and even fewer users will need to author new ones.
|
||||
Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters
|
||||
come with extensions pre-installed. As a result, most Kubernetes users will not need to install
|
||||
[extensions](/docs/concepts/extend-kubernetes/) and even fewer users will need to author new ones.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Garbage Collection
|
||||
id: garbage-collection
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/workloads/controllers/garbage-collection/
|
||||
full_link: /docs/concepts/architecture/garbage-collection/
|
||||
short_description: >
|
||||
A collective term for the various mechanisms Kubernetes uses to clean up cluster
|
||||
resources.
|
||||
@@ -12,13 +12,16 @@ tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
|
||||
cluster resources.
|
||||
|
||||
Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
|
||||
cluster resources.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
|
||||
Kubernetes uses garbage collection to clean up resources like
|
||||
[unused containers and images](/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
[failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
|
||||
that have expired or failed.
|
||||
that have expired or failed.
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for
|
||||
schema changes. The following descriptions cover both formats.
|
||||
|
||||
The API versioning and software versioning are indirectly related.
|
||||
The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md)
|
||||
The [API and release versioning proposal](https://git.k8s.io/sig-release/release-engineering/versioning.md)
|
||||
describes the relationship between API versioning and software versioning.
|
||||
|
||||
Different API versions indicate different levels of stability and support. You
|
||||
|
||||
@@ -13,10 +13,10 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
|
||||
* a highly available cluster
|
||||
* composable attributes
|
||||
* support for most popular Linux distributions
|
||||
* Ubuntu 16.04, 18.04, 20.04
|
||||
* Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 31, 32
|
||||
* Fedora 34, 35
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
@@ -33,7 +33,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g
|
||||
|
||||
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
|
||||
|
||||
* **Ansible v2.9 and python-netaddr are installed on the machine that will run Ansible commands**
|
||||
* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands**
|
||||
* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
|
||||
* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* The target servers are configured to allow **IPv4 forwarding**
|
||||
|
||||
@@ -69,4 +69,4 @@ admission controller. To get started with `cosigned` here are a few helpful
|
||||
resources:
|
||||
|
||||
* [Installation](https://github.com/sigstore/cosign#installation)
|
||||
* [Configuration Options](https://github.com/sigstore/cosign/tree/main/config)
|
||||
* [Configuration Options](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage)
|
||||
|
||||
+3
-4
@@ -362,9 +362,9 @@ and create it:
|
||||
kubectl create --validate=false -f my-crontab.yaml -o yaml
|
||||
```
|
||||
|
||||
your output is similar to:
|
||||
Your output is similar to:
|
||||
|
||||
```console
|
||||
```yaml
|
||||
apiVersion: stable.example.com/v1
|
||||
kind: CronTab
|
||||
metadata:
|
||||
@@ -836,7 +836,7 @@ Validation Rules Examples:
|
||||
| `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration |
|
||||
| `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' |
|
||||
| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 |
|
||||
| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the the int and string cases |
|
||||
| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the int and string cases |
|
||||
| `self.metadata.name.startsWith(self.prefix)` | Validate that an object's name has the prefix of another field value |
|
||||
| `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint |
|
||||
| `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet |
|
||||
@@ -844,7 +844,6 @@ Validation Rules Examples:
|
||||
|
||||
Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation)
|
||||
|
||||
|
||||
- If the Rule is scoped to the root of a resource, it may make field selection into any fields
|
||||
declared in the OpenAPIv3 schema of the CRD as well as `apiVersion`, `kind`, `metadata.name` and
|
||||
`metadata.generateName`. This includes selection of fields in both the `spec` and `status` in the
|
||||
|
||||
@@ -7,7 +7,7 @@ description: Configure the kubelet's image credential provider plugin
|
||||
content_type: task
|
||||
---
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="beta" >}}
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@ apiVersion: apiserver.k8s.io/v1beta1
|
||||
kind: EgressSelectorConfiguration
|
||||
egressSelections:
|
||||
# Since we want to control the egress traffic to the cluster, we use the
|
||||
# "cluster" as the name. Other supported values are "etcd", and "master".
|
||||
# "cluster" as the name. Other supported values are "etcd", and "controlplane".
|
||||
- name: cluster
|
||||
connection:
|
||||
# This controls the protocol between the API Server and the Konnectivity
|
||||
|
||||
@@ -7,7 +7,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl:5.34
|
||||
image: perl:5.34.0
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
backoffLimit: 4
|
||||
|
||||
@@ -8,11 +8,10 @@ spec:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: topology.kubernetes.io/zone
|
||||
- key: kubernetes.io/os
|
||||
operator: In
|
||||
values:
|
||||
- antarctica-east1
|
||||
- antarctica-west1
|
||||
- linux
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 1
|
||||
preference:
|
||||
|
||||
@@ -8,10 +8,11 @@ spec:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: kubernetes.io/os
|
||||
- key: topology.kubernetes.io/zone
|
||||
operator: In
|
||||
values:
|
||||
- linux
|
||||
- antarctica-east1
|
||||
- antarctica-west1
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 1
|
||||
preference:
|
||||
|
||||
@@ -78,7 +78,6 @@ releases may also occur in between these.
|
||||
|
||||
| Monthly Patch Release | Cherry Pick Deadline | Target date |
|
||||
| --------------------- | -------------------- | ----------- |
|
||||
| July 2022 | 2022-07-08 | 2022-07-13 |
|
||||
| August 2022 | 2022-08-12 | 2022-08-17 |
|
||||
| September 2022 | 2022-09-09 | 2022-09-14 |
|
||||
| October 2022 | 2022-10-07 | 2022-10-12 |
|
||||
@@ -87,24 +86,28 @@ releases may also occur in between these.
|
||||
|
||||
### 1.24
|
||||
|
||||
Next patch release is **1.24.1**
|
||||
Next patch release is **1.24.4**
|
||||
|
||||
End of Life for **1.24** is **2023-09-29**
|
||||
End of Life for **1.24** is **2023-07-28**
|
||||
|
||||
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.24.4 | 2022-08-12 | 2022-08-17 | |
|
||||
| 1.24.3 | 2022-07-08 | 2022-07-13 | |
|
||||
| 1.24.2 | 2022-06-10 | 2022-06-15 | |
|
||||
| 1.24.1 | 2022-05-20 | 2022-05-24 | |
|
||||
|
||||
### 1.23
|
||||
|
||||
Next patch release is **1.23.10**
|
||||
|
||||
**1.23** enters maintenance mode on **2022-12-28**.
|
||||
|
||||
End of Life for **1.23** is **2023-02-28**.
|
||||
|
||||
| Patch Release | Cherry Pick Deadline | Target Date | Note |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.23.10 | 2022-08-12 | 2022-08-17 | |
|
||||
| 1.23.9 | 2022-07-08 | 2022-07-13 | |
|
||||
| 1.23.8 | 2022-06-10 | 2022-06-15 | |
|
||||
| 1.23.7 | 2022-05-20 | 2022-05-24 | |
|
||||
@@ -117,12 +120,15 @@ End of Life for **1.23** is **2023-02-28**.
|
||||
|
||||
### 1.22
|
||||
|
||||
Next patch release is **1.22.13**
|
||||
|
||||
**1.22** enters maintenance mode on **2022-08-28**
|
||||
|
||||
End of Life for **1.22** is **2022-10-28**
|
||||
|
||||
| Patch Release | Cherry Pick Deadline | Target Date | Note |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.22.13 | 2022-08-12 | 2022-08-17 | |
|
||||
| 1.22.12 | 2022-07-08 | 2022-07-13 | |
|
||||
| 1.22.11 | 2022-06-10 | 2022-06-15 | |
|
||||
| 1.22.10 | 2022-05-20 | 2022-05-24 | |
|
||||
|
||||
@@ -4,8 +4,8 @@ type: docs
|
||||
---
|
||||
|
||||
"Release Managers" is an umbrella term that encompasses the set of Kubernetes
|
||||
contributors responsible for maintaining release branches, tagging releases,
|
||||
and building/packaging Kubernetes.
|
||||
contributors responsible for maintaining release branches and creating releases
|
||||
by using the tools SIG Release provides.
|
||||
|
||||
The responsibilities of each role are described below.
|
||||
|
||||
@@ -133,7 +133,9 @@ referred to as Release Manager shadows. They are responsible for:
|
||||
GitHub Mentions: @kubernetes/release-engineering
|
||||
|
||||
- Arnaud Meukam ([@ameukam](https://github.com/ameukam))
|
||||
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
|
||||
- Jim Angel ([@jimangel](https://github.com/jimangel))
|
||||
- Joseph Sandoval ([@jrsapi](https://github.com/jrsapi))
|
||||
- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
|
||||
- Max Körbächer ([@mkorbi](https://github.com/mkorbi))
|
||||
- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
|
||||
|
||||
@@ -124,7 +124,7 @@ The general labeling process should be consistent across artifact types.
|
||||
referring to a release MAJOR.MINOR `vX.Y` version.
|
||||
|
||||
See also
|
||||
[release versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md).
|
||||
[release versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md).
|
||||
|
||||
- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
|
||||
## Supported versions
|
||||
|
||||
Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
|
||||
For more information, see [Kubernetes Release Versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning).
|
||||
For more information, see [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning).
|
||||
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user