Week Ending November 24, 2024

https://lwkd.info/2024/20241127

Developer News

If you attended the Kubernetes Contributor Summit in Salt Lake City, please complete the post-event survey.

SIG-Security shared CVE-2024-10220, which allowed attackers to use a gitRepo volume for unauthorized file access. This vulnerability was patched in versions 1.31.0, 1.30.3, 1.29.7, and 1.28.12; if you are running older versions, please upgrade.

Release Schedule

Next Deadline: Release Highlights completion, December 3rd

Docs freeze is in effect as of Tuesday 26th November. We are now in the final phases of the v1.32 release cycle with the scheduled release date just two weeks away.

Kubernetes v1.32.0-rc.0 is live!. v1.32.0-rc.1 is scheduled to be cut on Monday, December 3rd.

KEP of the Week

KEP-3157: Allow informers for getting a stream of data instead of chunking

This KEP addresses the kube-apiserver’s vulnerability to excessive memory consumption caused by LIST requests in large clusters, which can lead to server crashes, node pressure, and workload disruption. To solve this, it proposes reducing temporary memory usage from an exponential scale to a manageable constant, leveraging the watch cache to reduce etcd load, ensuring consistent and fresh LIST responses, and maintaining backward compatibility—all while protecting the server and its node from OOM scenarios

This KEP is tracked for beta release in the ongoing v1.32 cycle.

Other Merges

Validate DRA Node Selector Labels even on upgraded objects; while this is a backwards-incompatible change, it’s not expected to break anything

Version Updates

golang to 1.23.3 in 1.32, and to 1.22.9 in older releases

via Last Week in Kubernetes Development https://lwkd.info/

November 27, 2024 at 05:00PM

Ask Me Anything about DevOps, Cloud, Kubernetses, or anything else

We are restarting AMA sessions. This time, there are not restrictions. You can ask anything about anything.

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

via YouTube https://www.youtube.com/watch?v=KO7T-nex5u4

Argo CD GitOps Promotions with Kargo (by Akuity): A Brilliant Idea with Flawed Execution?

In this deep dive, we explore how Kargo standardizes promotions, offering visibility and guardrails for your CI/CD pipelines. Learn how to integrate Kargo with Argo CD, manage multi-stage deployments, and tackle the challenges of modern DevOps workflows. Watch now to see Kargo in action and find out if it's the right tool for your DevOps toolkit.

Kargo #Akuity #ArgoCD

Consider joining the channel: https://www.youtube.com/c/devopstoolkit/join

▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬ ➡ Transcript and commands: https://devopstoolkit.live/ci-cd/argo-cd-gitops-promotions-with-kargo-by-akuity-a-brilliant-idea-with-flawed-execution? 🔗 Kargo: https://kargo.io 🎬 GitOps playlist: https://youtube.com/playlist?list=PLyicRj904Z99dJk8bOygbov5up5YYvoZV 🎬 SemVer: https://github.com/masterminds/semver

▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬ If you are interested in sponsoring this channel, please visit https://devopstoolkit.live/sponsor for more information. Alternatively, feel free to contact me over Twitter or LinkedIn (see below).

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ BlueSky: https://vfarcic.bsky.social ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬ 🎤 Podcast: https://www.devopsparadox.com/ 💬 Live streams: https://www.youtube.com/c/DevOpsParadox

▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬ 00:00 Argo CD Promotions with Argo CD and Kargo 05:37 Argo CD ApplicationSet 08:00 Kargo (by Akuity) Promotion Definitions 15:16 Kargo Promotions in Action 23:38 Kargo Critique 28:15 Kargo Pros and Cons

via YouTube https://www.youtube.com/watch?v=RoY7Qu51zwU

Amazon ElastiCache version 8.0 for Valkey brings faster scaling and improved memory efficiency | Amazon Web Services

Today, we are adding support for Valkey 8.0 on Amazon ElastiCache. ElastiCache version 8.0 for Valkey brings faster scaling for ElastiCache Serverless and…

November 22, 2024 at 09:29AM

via Instapaper

Week Ending November 17, 2024

https://lwkd.info/2024/20241120

Developer News

KubeCon NA Salt Lake City was last week! The Kubernetes Contributor Summit was held on Monday, November 11th. Find the photos and meeting notes from the unconference discussions here.

When one Kubecon ends, another one starts: the CfP is open for the Maintainer Summit at Kubecon London. The Summit includes the Kubernetes Contributor Summit plus collaboration with other projects. CfPs for Kubecon Main Track and Colo Events are open as well. And if you’re going to be in Kubecon India, don’t skip the Maintainer Summit there.

There have been some updates to SIG leadership. Richa Banker is nominated as the new chair for SIG Instrumentation and Marko Mudrinić is nominated as a Tech Lead for SIG K8S Infra. Congratulations and thank you for all your work!

Release Schedule

Next Deadline: Docs Freeze, November 26th

Code freeze is in effect from the past week. So far we have 44 enhancements tracked for v1.32 after code freeze. Out of these 18 are in alpha stage, 12 graduating to beta, 13 graduating to GA and one KEP is a deprecation.

The Docs Freeze deadline is coming up. If your KEP is tracked for v1.32, please make sure to get your docs PRs reviewed and merged before the Docs Freeze.

Patch releases 1.29.11, 1.30.7, 1.31.3 are now available.

Other Merges

The DRA kubelet API has its own protobuf package

Adjust resize policy validation to be backwards-compatible

Promotions

InPlacePodVerticalScaling to Beta

via Last Week in Kubernetes Development https://lwkd.info/

November 20, 2024 at 05:00PM

Gateway API v1.2: WebSockets, Timeouts, Retries, and More

https://kubernetes.io/blog/2024/11/21/gateway-api-v1-2/

Kubernetes SIG Network is delighted to announce the general availability of Gateway API v1.2! This version of the API was released on October 3, and we're delighted to report that we now have a number of conformant implementations of it for you to try out.

Gateway API v1.2 brings a number of new features to the Standard channel (Gateway API's GA release channel), introduces some new experimental features, and inaugurates our new release process — but it also brings two breaking changes that you'll want to be careful of.

Breaking changes

GRPCRoute and ReferenceGrant v1alpha2 removal

Now that the v1 versions of GRPCRoute and ReferenceGrant have graduated to Standard, the old v1alpha2 versions have been removed from both the Standard and Experimental channels, in order to ease the maintenance burden that perpetually supporting the old versions would place on the Gateway API community.

Before upgrading to Gateway API v1.2, you'll want to confirm that any implementations of Gateway API have been upgraded to support the v1 API version of these resources instead of the v1alpha2 API version. Note that even if you've been using v1 in your YAML manifests, a controller may still be using v1alpha2 which would cause it to fail during this upgrade. Additionally, Kubernetes itself goes to some effort to stop you from removing a CRD version that it thinks you're using: check out the release notes for more information about what you need to do to safely upgrade.

Change to .status.supportedFeatures (experimental)

A much smaller breaking change: .status.supportedFeatures in a Gateway is now a list of objects instead of a list of strings. The objects have a single name field, so the translation from the strings is straightforward, but moving to objects permits a lot more flexibility for the future. This stanza is not yet present in the Standard channel.

Graduations to the standard channel

Gateway API 1.2.0 graduates four features to the Standard channel, meaning that they can now be considered generally available. Inclusion in the Standard release channel denotes a high level of confidence in the API surface and provides guarantees of backward compatibility. Of course, as with any other Kubernetes API, Standard channel features can continue to evolve with backward-compatible additions over time, and we certainly expect further refinements and improvements to these new features in the future. For more information on how all of this works, refer to the Gateway API Versioning Policy.

HTTPRoute timeouts

GEP-1742 introduced the timeouts stanza into HTTPRoute, permitting configuring basic timeouts for HTTP traffic. This is a simple but important feature for proper resilience when handling HTTP traffic, and it is now Standard.

For example, this HTTPRoute configuration sets a timeout of 300ms for traffic to the /face path:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: face-with-timeouts namespace: faces spec: parentRefs:

• name: my-gateway kind: Gateway rules:
• matches:
• path: type: PathPrefix value: /face backendRefs:
• name: face port: 80 timeouts: request: 300ms

For more information, check out the HTTP routing documentation. (Note that this applies only to HTTPRoute timeouts. GRPCRoute timeouts are not yet part of Gateway API.)

Gateway infrastructure labels and annotations

Gateway API implementations are responsible for creating the backing infrastructure needed to make each Gateway work. For example, implementations running in a Kubernetes cluster often create Services and Deployments, while cloud-based implementations may be creating cloud load balancer resources. In many cases, it can be helpful to be able to propagate labels or annotations to these generated resources.

In v1.2.0, the Gateway infrastructure stanza moves to the Standard channel, allowing you to specify labels and annotations for the infrastructure created by the Gateway API controller. For example, if your Gateway infrastructure is running in-cluster, you can specify both Linkerd and Istio injection using the following Gateway configuration, making it simpler for the infrastructure to be incorporated into whichever service mesh you've installed:

apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: meshed-gateway namespace: incoming spec: gatewayClassName: meshed-gateway-class listeners:

• name: http-listener protocol: HTTP port: 80 infrastructure: labels: istio-injection: enabled annotations: linkerd.io/inject: enabled

For more information, check out the infrastructure API reference.

Backend protocol support

Since Kubernetes v1.20, the Service and EndpointSlice resources have supported a stable appProtocol field to allow users to specify the L7 protocol that Service supports. With the adoption of KEP 3726, Kubernetes now supports three new appProtocol values:

kubernetes.io/h2c

HTTP/2 over cleartext as described in RFC7540

kubernetes.io/ws

WebSocket over cleartext as described in RFC6445

kubernetes.io/wss

WebSocket over TLS as described in RFC6445

With Gateway API 1.2.0, support for honoring appProtocol is now Standard. For example, given the following Service:

apiVersion: v1 kind: Service metadata: name: websocket-service namespace: my-namespace spec: selector: app.kubernetes.io/name: websocket-app ports:

• name: http port: 80 targetPort: 9376 protocol: TCP appProtocol: kubernetes.io/ws

then an HTTPRoute that includes this Service as a backendRef will automatically upgrade the connection to use WebSockets rather than assuming that the connection is pure HTTP.

For more information, check out GEP-1911.

New additions to experimental channel

Named rules for *Route resources

The rules field in HTTPRoute and GRPCRoute resources can now be named, in order to make it easier to reference the specific rule, for example:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: multi-color-route namespace: faces spec: parentRefs:

• name: my-gateway kind: Gateway port: 80 rules:
• name: center-rule matches:
• path: type: PathPrefix value: /color/center backendRefs:
• name: color-center port: 80
• name: edge-rule matches:
• path: type: PathPrefix value: /color/edge backendRefs:
• name: color-edge port: 80

Logging or status messages can now refer to these two rules as center-rule or edge-rule instead of being forced to refer to them by index. For more information, see GEP-995.

HTTPRoute retry support

Gateway API 1.2.0 introduces experimental support for counted HTTPRoute retries. For example, the following HTTPRoute configuration retries requests to the /face path up to 3 times with a 500ms delay between retries:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: face-with-retries namespace: faces spec: parentRefs:

• name: my-gateway kind: Gateway port: 80 rules:
• matches:
• path: type: PathPrefix value: /face backendRefs:
• name: face port: 80 retry: codes: [ 500, 502, 503, 504 ] attempts: 3 backoff: 500ms

For more information, check out GEP 1731.

HTTPRoute percentage-based mirroring

Gateway API has long supported the Request Mirroring feature, which allows sending the same request to multiple backends. In Gateway API 1.2.0, we're introducing percentage-based mirroring, which allows you to specify a percentage of requests to mirror to a different backend. For example, the following HTTPRoute configuration mirrors 42% of requests to the color-mirror backend:

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: color-mirror-route namespace: faces spec: parentRefs:

• name: mirror-gateway hostnames:
• mirror.example rules:
• backendRefs:
• name: color port: 80 filters:
• type: RequestMirror requestMirror: backendRef: name: color-mirror port: 80 percent: 42 # This value must be an integer.

There's also a fraction stanza which can be used in place of percent, to allow for more precise control over exactly what amount of traffic is mirrored, for example:

... filters:

• type: RequestMirror requestMirror: backendRef: name: color-mirror port: 80 fraction: numerator: 1 denominator: 10000

This configuration mirrors 1 in 10,000 requests to the color-mirror backend, which may be relevant with very high request rates. For more details, see GEP-1731.

Additional backend TLS configuration

This release includes three additions related to TLS configuration for communications between a Gateway and a workload (a backend):

A new backendTLS field on Gateway

This new field allows you to specify the client certificate that a Gateway should use when connecting to backends.

A new subjectAltNames field on BackendTLSPolicy

Previously, the hostname field was used to configure both the SNI that a Gateway should send to a backend and the identity that should be provided by a certificate. When the new subjectAltNames field is specified, any certificate matching at least one of the specified SANs will be considered valid. This is particularly critical for SPIFFE where URI-based SANs may not be valid SNIs.

A new options field on BackendTLSPolicy

Similar to the TLS options field on Gateway Listeners, we believe the same concept will be broadly useful for TLS-specific configuration for Backend TLS.

For more information, check out GEP-3135.

More changes

For a full list of the changes included in this release, please refer to the v1.2.0 release notes.

Project updates

Beyond the technical, the v1.2 release also marks a few milestones in the life of the Gateway API project itself.

Release process improvements

Gateway API has never been intended to be a static API, and as more projects use it as a component to build on, it's become clear that we need to bring some more predictability to Gateway API releases. To that end, we're pleased - and a little ne