Flux CD has released version 2.2.0, a tool for keeping Kubernetes clusters in sync with sources of configuration and automating updates to configuration when there is new code to deploy. This feature release brings several updates and improvements to provide users with the best experience.

The Flux CLI and controllers have been updated to support Kustomize v5.3.0 and Kubernetes v1.28.4. This ensures compatibility with the latest versions and improves performance and stability.

One of the major updates in this release is the significant overhaul of the Flux helm-controller’s reconciliation model. This addresses persistent issues such as the automatic recovery of releases stuck in a pending state. It also improves the observability of the release status and introduces the ability to enable drift detection on a per-object basis. More details on the helm-controller improvements can be found in the Announcing Flux 2.2 GA blog post.

The Flux CLI now allows users to force or reset the reconciliation state of a HelmRelease v2beta2 object using the flux reconcile hr --force and flux reconcile hr --reset commands. This gives users more control over the deployment process.

The Flux CLI also comes with support for bootstrapping Gitea repositories, providing users with more options for managing their configuration sources. It also adds guardrails to flux install and flux bootstrap to protect users from destructive operations. Additionally, the flux version and flux check commands now print the Flux distribution version deployed on the cluster, making it easier for users to keep track of their Flux installation.

The alerting capabilities of Flux have been extended with support for NATS and Bitbucket Server & Data Center. This allows users to use these additional notification providers for alerting and monitoring purposes.

Starting with this release, Flux minor versions are benchmarked to measure the Mean Time To Production (MTTP), providing users with valuable insights into the performance of Flux.

The release is compatible with Kubernetes versions 1.26, 1.27, and 1.28.

The API changes in this release include the promotion of the HelmRelease kind from v2beta1 to v2beta2. The v2beta2 API is backwards compatible with v2beta1, and the v2beta1 API is deprecated and will be removed in a future release. Several new fields have been added, including drift detection and correction on a per-release basis, selective running of Helm tests, and a history of metadata from Helm releases. The Alert and Provider kinds have also been promoted from v1beta2 to v1beta3, with the removal of the .status field. The Bucket API now has a new field for server-side filtering of files, and the OCIRepository and HelmChart APIs have new fields for verifying OIDC identity. The HelmRepository and ImageRepository APIs have a new boolean field for connecting to non-TLS HTTP container registries.

To upgrade to Flux v2.2.0, users can either rerun the bootstrap process or use the Flux GitHub Action. The APIs can be upgraded by deploying the new CRDs and controllers and changing the manifests in Git. It is advised not to delay this procedure as the deprecated versions will be removed after 6 months.

The release also includes new documentation for the HelmRelease v2beta2 specification and a guide on enabling in-memory Kustomize builds.

Overall, Flux v2.2.0 brings several updates and improvements to provide users with a better experience in managing their Kubernetes clusters and configuration sources. Users are encouraged to upgrade to this version for the best experience.

The latest version of the web server Caddy, version v2.7.6, has just been released. This update brings several fixes and enhancements, thanks to the contributions of various contributors. While most of the changes are small, there are a few notable ones worth mentioning.

One significant improvement is the official extensibility of the templates middleware. This experimental feature allows modules to add custom functions and actions for templates to execute, providing more flexibility for developers.

Another important enhancement is the synchronized TLS storage cleaning across the cluster, which is now remembered across restarts. This improvement is particularly beneficial for expensive storage backends, as it significantly reduces costs.

In addition, placeholders are now evaluated in the configuration for certificate loaders, enabling more dynamic and flexible configurations.

The release also includes numerous bug fixes, addressing various issues reported by users and improving the overall stability and reliability of the web server.

To view the complete list of changes and contributions, you can refer to the changelog on the official Caddy GitHub repository.

K3s, a lightweight and highly available Kubernetes distribution, has released version v1.28.4+k3s1. This certified Kubernetes distribution is specifically designed for production workloads in resource-constrained and unattended environments, such as remote locations or IoT appliances. The new release updates Kubernetes to v1.28.4 and includes several fixes for various issues.

Some of the changes and improvements in this release include:

• Update channels latest to v1.27.7+k3s2
• Add etcd status condition for easy monitoring of etcd status from each node
• Automatic discovery of WebAssembly runtimes
• Improved dualStack log
• Optimized Dockerfile for simplified installation and runtime
• Addition of timezone info in the Docker image, enabling the use of spec.timeZone in CronJobs
• Bumped kine to v0.11.0, resolving issues with postgres and NATS, improving watch channel performance, and enhancing compatibility
• QoS-class resource configuration for containerd
• Addition of agent flag disable-apiserver-lb to disable load balance proxy
• Various bug fixes and improvements

For a full list of changes, please refer to the Kubernetes release notes.

The embedded component versions in this release are as follows:

• Kubernetes v1.28.4
• Kine v0.11.0
• SQLite 3.42.0
• Etcd v3.5.9-k3s1
• Containerd v1.7.7-k3s1
• Runc v1.1.8
• Flannel v0.22.2
• Metrics-server v0.6.3
• Traefik v2.10.5
• CoreDNS v1.10.1
• Helm-controller v0.15.4
• Local-path-provisioner v0.0.24

For more information and resources on K3s, you can visit the official documentation, join the Slack channel, or contribute to the project on GitHub.

Portainer has published an article titled “GitOps - The Path Forward” that explores the concept of GitOps and how it can be implemented using the Portainer platform. The article begins by discussing the importance of adhering to compliance standards like GDPR and the need for secure cloud environments. GitOps is presented as a recommended operational framework for implementing infrastructure and development methodologies that ensure compliance and effective infrastructure management.

The article goes on to explain the fundamental concepts of GitOps, including automation, version control, continuous integration/continuous delivery, auditing, compliance, version rollback, and collaboration. It highlights the requirements for implementing GitOps, such as Infrastructure as Code (IaC), pull request reviews, CI/CD pipelines, automation, version control, auditability, rollback and forward capabilities, and collaboration.

The article then focuses on how Portainer facilitates the implementation of GitOps. It mentions that Portainer offers a suite of tools designed specifically for GitOps, including RBAC, automation, and visibility. It highlights the role-based access control (RBAC) feature of Portainer, which provides precise access control to Kubernetes platforms and container runtime environments. Portainer also integrates with authentication providers like LDAP and Microsoft AD. The article further explains how Portainer enables GitOps automation by connecting with Git repositories and allowing for automated application deployment to Kubernetes clusters and container environments. It also mentions how Portainer provides updates and monitoring solutions for GitOps operations through container logs, authentication logs, and event lists.

In conclusion, the article emphasizes that GitOps is a contemporary methodology for managing infrastructure and applications, and leveraging GitOps strategies like auditing, rollback, and roll forward can enhance operational agility, reliability, and compliance. The article highlights the benefits of using the Portainer platform for implementing GitOps, including RBAC, automation, and monitoring capabilities.

Netmaker, a tool that creates networks using WireGuard, has released version v0.21.2. This tool automates the creation of fast, secure, and distributed virtual networks. Netmaker leverages Kernel WireGuard, which provides maximum speed, performance, and security for the virtual networks it creates.

The latest release, v0.21.2, brings several improvements and fixes to Netmaker. Some of the new features include auto relay via enrollment key and improvements in local routing.

In terms of fixes, the release addresses an inconsistency in DNS entries for networks, ensures validation of unique network CIDR, fixes caching discrepancies in extclient, resolves issues with deleted node peer updates when disconnected from the network, and adds a force deletion option for daemon nodes stuck in the removing state.

However, there are a few known issues with this release. The Windows installer does not install WireGuard, and the netclient-gui may continuously display an error dialog if the Netmaker server is offline. Additionally, there are IPv6 address and route issues on Mac, and the network tab in netclient-gui may appear blank after disconnecting.

Overall, Netmaker’s latest release offers improved functionality and fixes for a smoother experience in creating virtual networks with WireGuard.

Gitea has released version 1.21.0, which includes numerous new features and improvements. The release consists of 962 pull requests and marks the departure of Gitea Actions from the experimental state. Users can download the new version from the Gitea website.

The release includes several breaking changes that may affect users. One change involves moving public asset files to the proper directory. Previously, these files were served under a different directory, causing confusion for users. To resolve this, the default assets folder has been changed, and users with custom asset files will need to transfer them to the new location.

Another breaking change involves the configuration option for SSH authorized keys backup. Previously, this option was set to automatically create backups of the authorized keys file when a new SSH key was added. However, this caused the backup folder to become excessively large on instances with many users. As a result, the default value of this parameter has been changed, and users who still want backups should manually set it to true.

Additionally, the release removes the CHARSET configuration option for MySQL and always uses utf8mb4. Using utf8 as a charset for MySQL can lead to issues, and as Gitea only supports MySQL v5.7+, support for utf8 is no longer necessary. Existing utf8 databases will continue to work, but users are strongly encouraged to convert them to utf8mb4.

The release also includes improvements to Gitea Actions. Several new features have been added, including scheduled workflows, disabling workflows, and downloading raw task logs. Additionally, the admin page has been enhanced with capabilities such as manually rebuilding the issue index and a details page for each user.

Other notable improvements include the ability to select a specific commit range when reviewing a pull request, notifications for recently pushed branches, support for CODEOWNERS files, and the ability to pre-register OAuth2 applications for git credential helpers.

The release also introduces archived labels, a new concept that allows users to retire labels without deleting them. Gitea Actions have received various enhancements, making them a mature component of Gitea. The blame view has been simplified, and it is now possible to retry failed pull mirror creations.

Furthermore, the release includes improvements to the admin page, the ability to see if the CI is currently successful for all branches, and optimizations to reduce database deadlocks.

Looking ahead, Gitea 1.22 is expected to bring changes to the default themes and drop support for older database versions. The default themes will be renamed, and a new dark theme will be introduced. Users are encouraged to update their database versions for compatibility and security.

Overall, the release of Gitea 1.21.0 brings a range of new features and improvements that enhance the functionality and user experience of the platform. Users are encouraged to update to the latest version to take advantage of these enhancements.