Kubernetes on Producthunt daily

helm

Fri, 31 Oct 2025 15:27:26 +0800

helm/helm

Helm

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources.

Use Helm to:

Find and use popular software packaged as Helm Charts to run in Kubernetes
Share your own applications as Helm Charts
Create reproducible builds of your Kubernetes applications
Intelligently manage your Kubernetes manifest files
Manage releases of Helm packages

Helm in a Handbasket

Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like apt/yum/homebrew for Kubernetes.

Helm renders your templates and communicates with the Kubernetes API
Helm runs on your laptop, CI/CD, or wherever you want it to run.
Charts are Helm packages that contain at least two things:
- A description of the package (Chart.yaml)
- One or more templates, which contain Kubernetes manifest files
Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)

Helm Development and Stable Versions

Helm v4 is currently under development on the main branch. This is unstable and the APIs within the Go SDK and at the command line are changing. Helm v3 (current stable) is maintained on the dev-v3 branch. APIs there follow semantic versioning.

Install

Binary downloads of the Helm client can be found on the Releases page.

Unpack the helm binary and add it to your PATH and you are good to go!

If you want to use a package manager:

Homebrew users can use brew install helm.
Chocolatey users can use choco install kubernetes-helm.
Winget users can use winget install Helm.Helm.
Scoop users can use scoop install helm.
Snapcraft users can use snap install helm --classic.
Flox users can use flox install kubernetes-helm.

To rapidly get Helm up and running, start with the Quick Start Guide.

See the installation guide for more options, including installing pre-releases.

Docs

Get started with the Quick Start guide or plunge into the complete documentation.

Roadmap

The Helm roadmap uses GitHub milestones to track the progress of the project.

The development of Helm v4 is currently happening on the main branch while the development of Helm v3, the stable branch, is happening on the dev-v3 branch. Changes should be made to the main branch prior to being added to the dev-v3 branch so that all changes are carried along to Helm v4.

Community, discussion, contribution, and support

You can reach the Helm community and developers via the following channels:

Kubernetes Slack:
Mailing List:
- Helm Mailing List
Developer Call: Thursdays at 9:30-10:00 Pacific (meeting details)

Contribution

If you’re interested in contributing, please refer to the Contributing Guide before submitting a pull request.

Code of conduct

Participation in the Helm community is governed by the Code of Conduct.

istio

Thu, 25 Sep 2025 15:28:48 +0800

istio/istio

Istio

Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring – with few or no service code changes.

For in-depth information about how to use Istio, visit istio.io
To ask questions and get assistance from our community, visit Github Discussions
To learn how to participate in our overall community, visit our community page

In this README:

In addition, here are some other documents you may wish to read:

Istio Community - describes how to get involved and contribute to the Istio project
Istio Developer’s Guide - explains how to set up and use an Istio development environment
Project Conventions - describes the conventions we use within the code base
Creating Fast and Lean Code - performance-oriented advice and guidelines for the code base

You’ll find many other useful documents on our Wiki.

Introduction

Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio’s control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes.

Istio is composed of these components:

Envoy - Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.

Note: The service mesh is not an overlay network. It simplifies and enhances how microservices in an application talk to each other over the network provided by the underlying platform.
Istiod - The Istio control plane. It provides service discovery, configuration and certificate management. It consists of the following sub-components:
- Pilot - Responsible for configuring the proxies at runtime.
- Citadel - Responsible for certificate issuance and rotation.
- Galley - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.
Operator - The component provides user friendly options to operate the Istio service mesh.

Repositories

The Istio project is divided across a few GitHub repositories:

istio/api. This repository defines component-level APIs and common configuration formats for the Istio platform.
istio/community. This repository contains information on the Istio community, including the various documents that govern the Istio open source project.
istio/istio. This is the main code repository. It hosts Istio’s core components, install artifacts, and sample programs. It includes:
- istioctl. This directory contains code for the istioctl command line utility.
- pilot. This directory contains platform-specific code to populate the abstract service model, dynamically reconfigure the proxies when the application topology changes, as well as translate routing rules into proxy specific configuration.
- security. This directory contains security related code, including Citadel (acting as Certificate Authority), citadel agent, etc.
istio/proxy. The Istio proxy contains extensions to the Envoy proxy (in the form of Envoy filters) that support authentication, authorization, and telemetry collection.
istio/ztunnel. The repository contains the Rust implementation of the ztunnel component of Ambient mesh.
istio/client-go. This repository defines auto-generated Kubernetes clients for interacting with Istio resources programmatically.

[!NOTE] Only the istio/api and istio/client-go repositories expose stable interfaces intended for direct usage as libraries.

Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

Epic. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things. Each issue is ultimately part of an epic.
Milestone. Each issue is assigned a milestone. This is 0.1, 0.2, …, or ‘Nebulous Future’. The milestone indicates when we think the issue should get addressed.
Priority. Each issue has a priority which is represented by the column in the Prioritization project. Priority can be one of P0, P1, P2, or >P2. The priority indicates how important it is to address the issue within the milestone. P0 says that the milestone cannot be considered achieved if the issue isn’t resolved.

Istio is a Cloud Native Computing Foundation project.

loki

Sun, 21 Sep 2025 15:24:27 +0800

grafana/loki

Loki: like Prometheus, but for logs.

Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream.

Compared to other log aggregation systems, Loki:

does not do full text indexing on logs. By storing compressed, unstructured logs and only indexing metadata, Loki is simpler to operate and cheaper to run.
indexes and groups log streams using the same labels you’re already using with Prometheus, enabling you to seamlessly switch between metrics and logs using the same labels that you’re already using with Prometheus.
is an especially good fit for storing Kubernetes Pod logs. Metadata such as Pod labels is automatically scraped and indexed.
has native support in Grafana (needs Grafana v6.0).

A Loki-based logging stack consists of 3 components:

Alloy is agent, responsible for gathering logs and sending them to Loki.
Loki is the main service, responsible for storing logs and processing queries.
Grafana for querying and displaying the logs.

Note that Alloy replaced Promtail in the stack, because Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy.

Loki is like Prometheus, but for logs: we prefer a multidimensional label-based approach to indexing, and want a single-binary, easy to operate system with no dependencies. Loki differs from Prometheus by focusing on logs instead of metrics, and delivering logs via push, instead of pull.

Getting started

Upgrading

Upgrading Loki

Documentation

Latest release
Upcoming release, at the tip of the main branch

Commonly used sections:

API documentation for getting logs into Loki.
Labels
Operations
Promtail is an agent which tails log files and pushes them to Loki.
Pipelines details the log processing pipeline.
Docker Driver Client is a Docker plugin to send logs directly to Loki from Docker containers.
LogCLI provides a command-line interface for querying logs.
Loki Canary monitors your Loki installation for missing logs.
Troubleshooting presents help dealing with error messages.
Loki in Grafana describes how to set up a Loki datasource in Grafana.

Getting Help

If you have any questions or feedback regarding Loki:

Search existing thread in the Grafana Labs community forum for Loki: https://community.grafana.com
Ask a question on the Loki Slack channel. To invite yourself to the Grafana Slack, visit https://slack.grafana.com/ and join the #loki channel.
File an issue for bugs, issues and feature suggestions.
Send an email to lokiproject@googlegroups.com, or use the web interface.
UI issues should be filed directly in Grafana.

Your feedback is always welcome.

Contributing

Refer to CONTRIBUTING.md

Building from source

Loki can be run in a single host, no-dependencies mode using the following commands.

You need an up-to-date version of Go, we recommend using the version found in our Makefile

# Checkout source code
$ git clone https://github.com/grafana/loki
$ cd loki

# Build binary
$ go build ./cmd/loki

# Run executable
$ ./loki -config.file=./cmd/loki/loki-local-config.yaml

Alternatively, on Unix systems you can use make to build the binary, which adds additional arguments to the go build command.

# Build binary
$ make loki

# Run executable
$ ./cmd/loki/loki -config.file=./cmd/loki/loki-local-config.yaml

To build Promtail on non-Linux platforms, use the following command:

`1`	`$ go build ./clients/cmd/promtail`

On Linux, Promtail requires the systemd headers to be installed if Journal support is enabled. To enable Journal support the go build tag flag promtail_journal_enabled should be passed

With Journal support on Ubuntu, run with the following commands:

1
2

$ sudo apt install -y libsystemd-dev
$ go build --tags=promtail_journal_enabled ./clients/cmd/promtail

With Journal support on CentOS, run with the following commands:

1
2

$ sudo yum install -y systemd-devel
$ go build --tags=promtail_journal_enabled ./clients/cmd/promtail

Otherwise, to build Promtail without Journal support, run go build with CGO disabled:

`1`	`$ CGO_ENABLED=0 go build ./clients/cmd/promtail`

Adopters

Please see ADOPTERS.md for some of the organizations using Loki today. If you would like to add your organization to the list, please open a PR to add it to the list.

License

Grafana Loki is distributed under AGPL-3.0-only. For Apache-2.0 exceptions, see LICENSING.md.

airflow

Sun, 07 Sep 2025 15:25:12 +0800

apache/airflow

Apache Airflow

Badges
License
PyPI
Containers
Community

Version	Build Status
Main
3.x
2.x

Apache Airflow (or simply Airflow) is a platform to programmatically author, schedule, and monitor workflows.

When workflows are defined as code, they become more maintainable, versionable, testable, and collaborative.

Use Airflow to author workflows (Dags) that orchestrate tasks. The Airflow scheduler executes your tasks on an array of workers while following the specified dependencies. Rich command line utilities make performing complex surgeries on DAGs a snap. The rich user interface makes it easy to visualize pipelines running in production, monitor progress, and troubleshoot issues when needed.

Table of contents

Project Focus

Airflow works best with workflows that are mostly static and slowly changing. When the DAG structure is similar from one run to the next, it clarifies the unit of work and continuity. Other similar projects include Luigi, Oozie and Azkaban.

Airflow is commonly used to process data, but has the opinion that tasks should ideally be idempotent (i.e., results of the task will be the same, and will not create duplicated data in a destination system), and should not pass large quantities of data from one task to the next (though tasks can pass metadata using Airflow’s XCom feature). For high-volume, data-intensive tasks, a best practice is to delegate to external services specializing in that type of work.

Airflow is not a streaming solution, but it is often used to process real-time data, pulling data off streams in batches.

Principles

Dynamic: Pipelines are defined in code, enabling dynamic dag generation and parameterization.
Extensible: The Airflow framework includes a wide range of built-in operators and can be extended to fit your needs.
Flexible: Airflow leverages the Jinja templating engine, allowing rich customizations.

Requirements

Apache Airflow is tested with:

	Main version (dev)	Stable version (3.0.6)
Python	3.10, 3.11, 3.12, 3.13	3.9, 3.10, 3.11, 3.12
Platform	AMD64/ARM64(*)	AMD64/ARM64(*)
Kubernetes	1.30, 1.31, 1.32, 1.33	1.30, 1.31, 1.32, 1.33
PostgreSQL	13, 14, 15, 16, 17	13, 14, 15, 16, 17
MySQL	8.0, 8.4, Innovation	8.0, 8.4, Innovation
SQLite	3.15.0+	3.15.0+

* Experimental

Note: MariaDB is not tested/recommended.

Note: SQLite is used in Airflow tests. Do not use it in production. We recommend using the latest stable version of SQLite for local development.

Note: Airflow currently can be run on POSIX-compliant Operating Systems. For development, it is regularly tested on fairly modern Linux Distros and recent versions of macOS. On Windows you can run it via WSL2 (Windows Subsystem for Linux 2) or via Linux Containers. The work to add Windows support is tracked via #10388, but it is not a high priority. You should only use Linux-based distros as “Production” execution environment as this is the only environment that is supported. The only distro that is used in our CI tests and that is used in the Community managed DockerHub image is Debian Bookworm.

Getting started

Visit the official Airflow website documentation (latest stable release) for help with installing Airflow, getting started, or walking through a more complete tutorial.

Note: If you’re looking for documentation for the main branch (latest development branch): you can find it on s.apache.org/airflow-docs.

For more information on Airflow Improvement Proposals (AIPs), visit the Airflow Wiki.

Documentation for dependent projects like provider distributions, Docker image, Helm Chart, you’ll find it in the documentation index.

Installing from PyPI

We publish Apache Airflow as apache-airflow package in PyPI. Installing it however might be sometimes tricky because Airflow is a bit of both a library and application. Libraries usually keep their dependencies open, and applications usually pin them, but we should do neither and both simultaneously. We decided to keep our dependencies as open as possible (in pyproject.toml) so users can install different versions of libraries if needed. This means that pip install apache-airflow will not work from time to time or will produce unusable Airflow installation.

To have repeatable installation, however, we keep a set of “known-to-be-working” constraint files in the orphan constraints-main and constraints-2-0 branches. We keep those “known-to-be-working” constraints files separately per major/minor Python version. You can use them as constraint files when installing Airflow from PyPI. Note that you have to specify correct Airflow tag/version/branch and Python versions in the URL.

Installing just Airflow:

Note: Only pip installation is currently officially supported.

While it is possible to install Airflow with tools like Poetry or pip-tools, they do not share the same workflow as pip - especially when it comes to constraint vs. requirements management. Installing via Poetry or pip-tools is not currently supported.

There are known issues with bazel that might lead to circular dependencies when using it to install Airflow. Please switch to pip if you encounter such problems. Bazel community works on fixing the problem in this PR <https://github.com/bazelbuild/rules_python/pull/1166>_ so it might be that newer versions of bazel will handle it.

If you wish to install Airflow using those tools, you should use the constraint files and convert them to the appropriate format and workflow that your tool requires.

1
2

pip install 'apache-airflow==3.0.6' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.0.6/constraints-3.10.txt"

Installing with extras (i.e., postgres, google)

1
2

pip install 'apache-airflow[postgres,google]==3.0.6' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.0.6/constraints-3.10.txt"

For information on installing provider distributions, check providers.

Installation

For comprehensive instructions on setting up your local development environment and installing Apache Airflow, please refer to the INSTALLING.md file.

Official source code

Apache Airflow is an Apache Software Foundation (ASF) project, and our official source code releases:

Follow the ASF Release Policy
Can be downloaded from the ASF Distribution Directory
Are cryptographically signed by the release manager
Are officially voted on by the PMC members during the Release Approval Process

Following the ASF rules, the source packages released must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools.

Convenience packages

There are other ways of installing and using Airflow. Those are “convenience” methods - they are not “official releases” as stated by the ASF Release Policy, but they can be used by the users who do not want to build the software themselves.

Those are - in the order of most common ways people install Airflow:

PyPI releases to install Airflow using standard pip tool
Docker Images to install airflow via docker tool, use them in Kubernetes, Helm Charts, docker-compose, docker swarm, etc. You can read more about using, customizing, and extending the images in the Latest docs, and learn details on the internals in the images document.
Tags in GitHub to retrieve the git project sources that were used to generate official source packages via git

All those artifacts are not official releases, but they are prepared using officially released sources. Some of those artifacts are “development” or “pre-release” ones, and they are clearly marked as such following the ASF Policy.

User Interface

DAGs: Overview of all DAGs in your environment.
Assets: Overview of Assets with dependencies.
Grid: Grid representation of a DAG that spans across time.
Graph: Visualization of a DAG’s dependencies and their current status for a specific run.
Home: Summary statistics of your Airflow environment.
Backfill: Backfilling a DAG for a specific date range.
Code: Quick way to view source code of a DAG.

Semantic versioning

As of Airflow 2.0.0, we support a strict SemVer approach for all packages released.

There are few specific rules that we agreed to that define details of versioning of the different packages:

Airflow: SemVer rules apply to core airflow only (excludes any changes to providers). Changing limits for versions of Airflow dependencies is not a breaking change on its own.
Airflow Providers: SemVer rules apply to changes in the particular provider’s code only. SemVer MAJOR and MINOR versions for the packages are independent of the Airflow version. For example, google 4.1.0 and amazon 3.0.6 providers can happily be installed with Airflow 2.1.2. If there are limits of cross-dependencies between providers and Airflow packages, they are present in providers as install_requires limitations. We aim to keep backwards compatibility of providers with all previously released Airflow 2 versions but there will sometimes be breaking changes that might make some, or all providers, have minimum Airflow version specified.
Airflow Helm Chart: SemVer rules apply to changes in the chart only. SemVer MAJOR and MINOR versions for the chart are independent of the Airflow version. We aim to keep backwards compatibility of the Helm Chart with all released Airflow 2 versions, but some new features might only work starting from specific Airflow releases. We might however limit the Helm Chart to depend on minimal Airflow version.
Airflow API clients: Their versioning is independent from Airflow versions. They follow their own SemVer rules for breaking changes and new features - which for example allows to change the way we generate the clients.

Version Life Cycle

Apache Airflow version life cycle:

Version	Current Patch/Minor	State	First Release	Limited Maintenance	EOL/Terminated
3	3.0.6	Supported	Apr 22, 2025	TBD	TBD
2	2.11.0	Supported	Dec 17, 2020	Oct 22, 2025	Apr 22, 2026
1.10	1.10.15	EOL	Aug 27, 2018	Dec 17, 2020	June 17, 2021
1.9	1.9.0	EOL	Jan 03, 2018	Aug 27, 2018	Aug 27, 2018
1.8	1.8.2	EOL	Mar 19, 2017	Jan 03, 2018	Jan 03, 2018
1.7	1.7.1.2	EOL	Mar 28, 2016	Mar 19, 2017	Mar 19, 2017

Limited support versions will be supported with security and critical bug fix only. EOL versions will not get any fixes nor support. We always recommend that all users run the latest available minor release for whatever major version is in use. We highly recommend upgrading to the latest Airflow major release at the earliest convenient time and before the EOL date.

Support for Python and Kubernetes versions

As of Airflow 2.0, we agreed to certain rules we follow for Python and Kubernetes support. They are based on the official release schedule of Python and Kubernetes, nicely summarized in the Python Developer’s Guide and Kubernetes version skew policy.

We drop support for Python and Kubernetes versions when they reach EOL. Except for Kubernetes, a version stays supported by Airflow if two major cloud providers still provide support for it. We drop support for those EOL versions in main right after EOL date, and it is effectively removed when we release the first new MINOR (Or MAJOR if there is no new MINOR version) of Airflow. For example, for Python 3.10 it means that we will drop support in main right after 27.06.2023, and the first MAJOR or MINOR version of Airflow released after will not have it.
We support a new version of Python/Kubernetes in main after they are officially released, as soon as we make them work in our CI pipeline (which might not be immediate due to dependencies catching up with new versions of Python mostly) we release new images/support in Airflow based on the working CI setup.
This policy is best-effort which means there may be situations where we might terminate support earlier if circumstances require it.

Base OS support for reference Airflow images

The Airflow Community provides conveniently packaged container images that are published whenever we publish an Apache Airflow release. Those images contain:

Base OS with necessary packages to install Airflow (stable Debian OS)
Base Python installation in versions supported at the time of release for the MINOR version of Airflow released (so there could be different versions for 2.3 and 2.2 line for example)
Libraries required to connect to supported Databases (again the set of databases supported depends on the MINOR version of Airflow)
Predefined set of popular providers (for details see the Dockerfile).
Possibility of building your own, custom image where the user can choose their own set of providers and libraries (see Building the image)
In the future Airflow might also support a “slim” version without providers nor database clients installed

The version of the base OS image is the stable version of Debian. Airflow supports using all currently active stable versions - as soon as all Airflow dependencies support building, and we set up the CI pipeline for building and testing the OS version. Approximately 6 months before the end-of-regular support of a previous stable version of the OS, Airflow switches the images released to use the latest supported version of the OS.

For example switch from Debian Bullseye to Debian Bookworm has been implemented before 2.8.0 release in October 2023 and Debian Bookworm will be the only option supported as of Airflow 2.10.0.

Users will continue to be able to build their images using stable Debian releases until the end of regular support and building and verifying of the images happens in our CI but no unit tests were executed using this image in the main branch.

Approach to dependencies of Airflow

Airflow has a lot of dependencies - direct and transitive, also Airflow is both - library and application, therefore our policies to dependencies has to include both - stability of installation of application, but also ability to install newer version of dependencies for those users who develop DAGs. We developed the approach where constraints are used to make sure airflow can be installed in a repeatable way, while we do not limit our users to upgrade most of the dependencies. As a result we decided not to upper-bound version of Airflow dependencies by default, unless we have good reasons to believe upper-bounding them is needed because of importance of the dependency as well as risk it involves to upgrade specific dependency. We also upper-bound the dependencies that we know cause problems.

The constraint mechanism of ours takes care about finding and upgrading all the non-upper bound dependencies automatically (providing that all the tests pass). Our main build failures will indicate in case there are versions of dependencies that break our tests - indicating that we should either upper-bind them or that we should fix our code/tests to account for the upstream changes from those dependencies.

Whenever we upper-bound such a dependency, we should always comment why we are doing it - i.e. we should have a good reason why dependency is upper-bound. And we should also mention what is the condition to remove the binding.

Approach for dependencies for Airflow Core

Those dependencies are maintained in pyproject.toml.

There are few dependencies that we decided are important enough to upper-bound them by default, as they are known to follow predictable versioning scheme, and we know that new versions of those are very likely to bring breaking changes. We commit to regularly review and attempt to upgrade to the newer versions of the dependencies as they are released, but this is manual process.

The important dependencies are:

SQLAlchemy: upper-bound to specific MINOR version (SQLAlchemy is known to remove deprecations and introduce breaking changes especially that support for different Databases varies and changes at various speed)
Alembic: it is important to handle our migrations in predictable and performant way. It is developed together with SQLAlchemy. Our experience with Alembic is that it very stable in MINOR version
Flask: We are using Flask as the back-bone of our web UI and API. We know major version of Flask are very likely to introduce breaking changes across those so limiting it to MAJOR version makes sense
werkzeug: the library is known to cause problems in new versions. It is tightly coupled with Flask libraries, and we should update them together
celery: Celery is a crucial component of Airflow as it used for CeleryExecutor (and similar). Celery follows SemVer, so we should upper-bound it to the next MAJOR version. Also, when we bump the upper version of the library, we should make sure Celery Provider minimum Airflow version is updated.
kubernetes: Kubernetes is a crucial component of Airflow as it is used for the KubernetesExecutor (and similar). Kubernetes Python library follows SemVer, so we should upper-bound it to the next MAJOR version. Also, when we bump the upper version of the library, we should make sure Kubernetes Provider minimum Airflow version is updated.

Approach for dependencies in Airflow Providers and extras

The main part of the Airflow is the Airflow Core, but the power of Airflow also comes from a number of providers that extend the core functionality and are released separately, even if we keep them (for now) in the same monorepo for convenience. You can read more about the providers in the Providers documentation. We also have set of policies implemented for maintaining and releasing community-managed providers as well as the approach for community vs. 3rd party providers in the providers document.

Those extras and providers dependencies are maintained in provider.yaml of each provider.

By default, we should not upper-bound dependencies for providers, however each provider’s maintainer might decide to add additional limits (and justify them with comment).

Contributing

Want to help build Apache Airflow? Check out our contributors’ guide for a comprehensive overview of how to contribute, including setup instructions, coding standards, and pull request guidelines.

If you can’t wait to contribute, and want to get started asap, check out the contribution quickstart here!

Official Docker (container) images for Apache Airflow are described in images.

Voting Policy

Commits need a +1 vote from a committer who is not the author
When we do AIP voting, both PMC member’s and committer’s +1s are considered a binding vote.

Who uses Apache Airflow?

We know about around 500 organizations that are using Apache Airflow (but there are likely many more) in the wild.

If you use Airflow - feel free to make a PR to add your organisation to the list.

Who maintains Apache Airflow?

Airflow is the work of the community, but the core committers/maintainers are responsible for reviewing and merging PRs as well as steering conversations around new feature requests. If you would like to become a maintainer, please review the Apache Airflow committer requirements.

What goes into the next release?

Often you will see an issue that is assigned to specific milestone with Airflow version, or a PR that gets merged to the main branch and you might wonder which release the merged PR(s) will be released in or which release the fixed issues will be in. The answer to this is as usual - it depends on various scenarios. The answer is different for PRs and Issues.

To add a bit of context, we are following the Semver versioning scheme as described in Airflow release process. More details are explained in detail in this README under the Semantic versioning chapter, but in short, we have MAJOR.MINOR.PATCH versions of Airflow.

MAJOR version is incremented in case of breaking changes
MINOR version is incremented when there are new features added
PATCH version is incremented when there are only bug-fixes and doc-only changes

Generally we release MINOR versions of Airflow from a branch that is named after the MINOR version. For example 2.7.* releases are released from v2-7-stable branch, 2.8.* releases are released from v2-8-stable branch, etc.

Most of the time in our release cycle, when the branch for next MINOR branch is not yet created, all PRs merged to main (unless they get reverted), will find their way to the next MINOR release. For example if the last release is 2.7.3 and v2-8-stable branch is not created yet, the next MINOR release is 2.8.0 and all PRs merged to main will be released in 2.8.0. However, some PRs (bug-fixes and doc-only changes) when merged, can be cherry-picked to current MINOR branch and released in the next PATCHLEVEL release. For example, if 2.8.1 is already released and we are working on 2.9.0dev, then marking a PR with 2.8.2 milestone means that it will be cherry-picked to v2-8-test branch and released in 2.8.2rc1, and eventually in 2.8.2.
When we prepare for the next MINOR release, we cut new v2-*-test and v2-*-stable branch and prepare alpha, beta releases for the next MINOR version, the PRs merged to main will still be released in the next MINOR release until rc version is cut. This is happening because the v2-*-test and v2-*-stable branches are rebased on top of main when next beta and rc releases are prepared. For example, when we cut 2.10.0beta1 version, anything merged to main before 2.10.0rc1 is released, will find its way to 2.10.0rc1.
Then, once we prepare the first RC candidate for the MINOR release, we stop moving the v2-*-test and v2-*-stable branches and the PRs merged to main will be released in the next MINOR release. However, some PRs (bug-fixes and doc-only changes) when merged, can be cherry-picked to current MINOR branch and released in the next PATCHLEVEL release - for example when the last released version from v2-10-stable branch is 2.10.0rc1, some of the PRs from main can be marked as 2.10.0 milestone by committers, the release manager will try to cherry-pick them into the release branch. If successful, they will be released in 2.10.0rc2 and subsequently in 2.10.0. This also applies to subsequent PATCHLEVEL versions. When for example 2.10.1 is already released, marking a PR with 2.10.2 milestone will mean that it will be cherry-picked to v2-10-stable branch and released in 2.10.2rc1 and eventually in 2.10.2.

The final decision about cherry-picking is made by the release manager.

Marking issues with a milestone is a bit different. Maintainers do not mark issues with a milestone usually, normally they are only marked in PRs. If PR linked to the issue (and “fixing it”) gets merged and released in a specific version following the process described above, the issue will be automatically closed, no milestone will be set for the issue, you need to check the PR that fixed the issue to see which version it was released in.

However, sometimes maintainers mark issues with specific milestone, which means that the issue is important to become a candidate to take a look when the release is being prepared. Since this is an Open-Source project, where basically all contributors volunteer their time, there is no guarantee that specific issue will be fixed in specific version. We do not want to hold the release because some issue is not fixed, so in such case release manager will reassign such unfixed issues to the next milestone in case they are not fixed in time for the current release. Therefore, the milestone for issue is more of an intent that it should be looked at, than promise it will be fixed in the version.

More context and FAQ about the patchlevel release can be found in the What goes into the next release document in the dev folder of the repository.

Can I use the Apache Airflow logo in my presentation?

Yes! Be sure to abide by the Apache Foundation trademark policies and the Apache Airflow Brandbook. The most up-to-date logos are found in this repo and on the Apache Software Foundation website.

kubesphere

Sun, 03 Aug 2025 15:29:40 +0800

kubesphere/kubesphere

The container platform tailored for Kubernetes multi-cloud, datacenter, and edge management

What is KubeSphere

English | 中文

KubeSphere is a distributed operating system for cloud-native application management, using Kubernetes as its kernel. It provides a plug-and-play architecture, allowing third-party applications to be seamlessly integrated into its ecosystem. KubeSphere is also a multi-tenant container platform with full-stack automated IT operation and streamlined DevOps workflows. It provides developer-friendly wizard web UI, helping enterprises to build out a more robust and feature-rich platform, which includes most common functionalities needed for enterprise Kubernetes strategy, see Feature List for details.

The following screenshots give a close insight into KubeSphere. Please check What is KubeSphere for further information.

Workbench	Project Resources

CI/CD Pipeline	App Store

Demo environment

🎮 KubeSphere Lite provides you with free, stable, and out-of-the-box managed cluster service. After registration and login, you can easily create a K8s cluster with KubeSphere installed in only 5 seconds and experience feature-rich KubeSphere.

🖥 You can view the Demo Video to get started with KubeSphere.

Features

🧩 Extensible Architecture

Designed for flexibility, supporting plugin-based extensions and seamless integrations. Easily customize and expand functionalities to meet evolving needs. Learn more.

🕸 Provisioning Kubernetes Cluster

Support deploy Kubernetes on any infrastructure, support online and air-gapped installation. Learn more.

🔗 Kubernetes Multi-cluster Management

Provide a centralized control plane to manage multiple Kubernetes clusters, and support the ability to propagate an app to multiple K8s clusters across different cloud providers.

🤖 Kubernetes DevOps

Provide GitOps-based CD solutions and use Argo CD to provide the underlying support, collecting CD status information in real time. With the mainstream CI engine Jenkins integrated, DevOps has never been easier. Learn more.

🔎 Cloud Native Observability

Multi-dimensional monitoring, events and auditing logs are supported; multi-tenant log query and collection, alerting and notification are built-in. Learn more.

🌐 Service Mesh (Istio-based)

Provide fine-grained traffic management, observability and tracing for distributed microservice applications, provides visualization for traffic topology. Learn more.

💻 App Store

Provide an App Store for Helm-based applications, and offer application lifecycle management on Kubernetes platform. Learn more.

💡 Edge Computing Platform

KubeSphere integrates KubeEdge to enable users to deploy applications on the edge devices and view logs and monitoring metrics of them on the console. Learn more.

🗃 Support Multiple Storage and Networking Solutions

Support GlusterFS, CephRBD, NFS, LocalPV solutions, and provide CSI plugins to consume storage from multiple cloud providers.

Provide Load Balancer Implementation OpenELB for Kubernetes in bare-metal, edge, and virtualization.

Provides network policy and Pod IP pools management, support Calico, Flannel, Kube-OVN

🏢 Multi-Tenancy

Isolated workspaces with role-based access control ensure secure resource sharing across multiple tenants. Supports fine-grained permissions and quota management. Learn more.

🧠 GPU Workloads Scheduling and Monitoring

Create GPU workloads on the GUI, schedule GPU resources, and manage GPU resource quotas by tenant.

Architecture

KubeSphere 4.x adopts a microkernel + extension components architecture (codename LuBan). The core part (KubeSphere Core) only includes the essential basic functions required for system operation, with independent functional modules split and provided in the form of extension components. Users can dynamically manage the extension components during system operation. With the extension capabilities, KubeSphere can support more application scenarios and meet the needs of different users.

Latest release

🎉 KubeSphere v4.1.2 was released! It brings enhancements and better user experience, see the Release Notes For 4.1.2 for the updates.

Installation

KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any version-compatible Kubernetes cluster. KubeSphere consumes very few resources, and you can optionally install additional extensions after installation.

Quick start

Installing on K8s

Run the following commands to install KubeSphere on an existing Kubernetes cluster:

`1`	`helm upgrade --install -n kubesphere-system --create-namespace ks-core https://charts.kubesphere.io/main/ks-core-1.1.3.tgz --debug --wait`

KubeSphere for hosted Kubernetes services

KubeSphere is hosted on the following cloud providers, and you can try KubeSphere by one-click installation on their hosted Kubernetes services.

You can also install KubeSphere on other hosted Kubernetes services within minutes, see the step-by-step guides to get started.

👨‍💻 No internet access? Refer to the Air-gapped Installation.

Guidance, discussion, contribution, and support

You can reach the KubeSphere community and developers via the following channels:

:hugs: Please submit any KubeSphere bugs, issues, and feature requests to KubeSphere GitHub Issue.

:heart_decoration: The KubeSphere team also provides efficient official ticket support to respond in hours. For more information, click KubeSphere Online Support.

Contribution

KubeSphere Development Guide explains how to build and develop KubeSphere.
KubeSphere Extension Development Guide explains how to develop KubeSphere extensions.

Code of conduct

Participation in the KubeSphere community is governed by the Code of Conduct.

Security

The security process for reporting vulnerabilities is described in SECURITY.md.

Who are using KubeSphere

The user case studies page includes the user list of the project. You can leave a comment to let us know your use case.

KubeSphere is a member of CNCF and a Kubernetes Conformance Certified platform , which enriches the CNCF CLOUD NATIVE Landscape.

learn-agentic-ai

Tue, 17 Jun 2025 15:30:43 +0800

panaversity/learn-agentic-ai

Learn Agentic AI using Dapr Agentic Cloud Ascent (DACA) Design Pattern: From Start to Scale

This repo is part of the Panaversity Certified Agentic & Robotic AI Engineer program. It covers AI-201, AI-202 and AI-301 courses.

We have Two Hunches, the future of Pakistan depends on it, let’s make sure that we are not wrong:

It is very important for Pakistan that we bet on the right horses for the upcoming age of Agentic AI. We will be training millions of Agentic AI Developers all over Pakistan and online around the world and building startups, we cant afford to be wrong.

Hunch #1: Dapr We feel Dapr, Dapr Actors, Dapr Workflows, and Dapr Agents will be the core technology in building the next generation multi ai agentic systems, is my hunch correct?

Hunch #2: OpenAI Agents SDK We also have a hunch that OpenAI Agents SDK will be the go to framework for beginners to start learning Agentic AI?

Let us see what the best AI has to say about our hunches:

https://chatgpt.com/share/6811b893-82cc-8001-9037-e45bcd91cc64

https://g.co/gemini/share/1f31c876520b

https://grok.com/share/bGVnYWN5_4343d342-c7df-4b06-9174-487a64f59d53

This Panaversity Initiative Tackles the Critical Challenge:

“How do we design AI Agents that can handle 10 million concurrent AI Agents without failing?”

Note: The challenge is intensified as we must guide our students to solve this issue with minimal financial resources available during training.

Kubernetes with Dapr can theoretically handle 10 million concurrent agents in an agentic AI system without failing, but achieving this requires extensive optimization, significant infrastructure, and careful engineering. While direct evidence at this scale is limited, logical extrapolation from existing benchmarks, Kubernetes’ scalability, and Dapr’s actor model supports feasibility, especially with rigorous tuning and resource allocation.

Condensed Argument with Proof and Logic:

Kubernetes Scalability:
- Evidence: Kubernetes supports up to 5,000 nodes and 150,000 pods per cluster (Kubernetes docs), with real-world examples like PayPal scaling to 4,000 nodes and 200,000 pods (InfoQ, 2023) and KubeEdge managing 100,000 edge nodes and 1 million pods (KubeEdge case studies). OpenAI’s 2,500-node cluster for AI workloads (OpenAI blog, 2022) shows Kubernetes can handle compute-intensive tasks.
- Logic: For 10 million users, a cluster of 5,000–10,000 nodes (e.g., AWS g5 instances with GPUs) can distribute workloads. Each node can run hundreds of pods, and Kubernetes’ horizontal pod autoscaling (HPA) dynamically adjusts to demand. Bottlenecks (e.g., API server, networking) can be mitigated by tuning etcd, using high-performance CNIs like Cilium, and optimizing DNS.
Dapr’s Efficiency for Agentic AI:
- Evidence: Dapr’s actor model supports thousands of virtual actors per CPU core with double-digit millisecond latency (Dapr docs, 2024). Case studies show Dapr handling millions of events, e.g., Tempestive’s IoT platform processing billions of messages (Dapr blog, 2023) and DeFacto’s system managing 3,700 events/second (320 million daily) on Kubernetes with Kafka (Microsoft case study, 2022).
- Logic: Agentic AI relies on stateful, low-latency agents. Dapr Agents, built on the actor model, can represent 10 million users as actors, distributed across a Kubernetes cluster. Dapr’s state management (e.g., Redis) and pub/sub messaging (e.g., Kafka) ensure efficient coordination and resilience, with automatic retries preventing failures. Sharding state stores and message brokers scales to millions of operations/second.
Handling AI Workloads:
- Evidence: LLM inference frameworks like vLLM and TGI serve thousands of requests/second per GPU (vLLM benchmarks, 2024). Kubernetes orchestrates GPU workloads effectively, as seen Kubernetes manages GPU workloads, as seen in NVIDIA’s AI platform scaling to thousands of GPUs (NVIDIA case study, 2023).
- Logic: Assuming each user generates 1 request/second requiring 0.01 GPU, 10 million users need ~100,000 GPUs. Batching, caching, and model parallelism reduce this to a feasible ~10,000–20,000 GPUs, achievable in hyperscale clouds (e.g., AWS). Kubernetes’ resource scheduling ensures optimal GPU utilization.
Networking and Storage:
- Evidence: EMQX on Kubernetes handled 1 million concurrent connections with tuning (EMQX blog, 2024). C10M benchmarks (2013) achieved 10 million connections using optimized stacks. Dapr’s state stores (e.g., Redis) support millions of operations/second (Redis benchmarks, 2024).
- Logic: 10 million connections require ~100–1,000 Gbps bandwidth, supported by modern clouds. High-throughput databases (e.g., CockroachDB) and caching (e.g., Redis Cluster) handle 10 TB of state data for 10 million users (1 KB/user). Kernel bypass (e.g., DPDK) and eBPF-based CNIs (e.g., Cilium) minimize networking latency.
Resilience and Monitoring:
- Evidence: Dapr’s resiliency policies (retries, circuit breakers) and Kubernetes’ self-healing (pod restarts) ensure reliability (Dapr docs, 2024). Dapr’s OpenTelemetry integration scales monitoring for millions of agents (Prometheus case studies, 2023).
- Logic: Real-time metrics (e.g., latency, error rates) and distributed tracing prevent cascading failures. Kubernetes’ liveness probes and Dapr’s workflow engine recover from crashes, ensuring 99.999% uptime.

Feasibility with Constraints:

Challenge: No direct benchmark exists for 10 million concurrent users with Dapr/Kubernetes in an agentic AI context. Infrastructure costs (e.g., $10M–$100M for 10,000 nodes) are prohibitive for low-budget scenarios.
Solution: Use open-source tools (e.g., Minikube, kind) for local testing and cloud credits (e.g., AWS Educate) for students. Simulate 10 million users with tools like Locust on smaller clusters (e.g., 100 nodes), extrapolating results. Optimize Dapr’s actor placement and Kubernetes’ resource quotas to maximize efficiency on limited hardware. Leverage free-tier databases (e.g., MongoDB Atlas) and message brokers (e.g., RabbitMQ).

Conclusion: Kubernetes with Dapr can handle 10 million concurrent users in an agentic AI system, supported by their proven scalability, real-world case studies, and logical extrapolation. For students with minimal budgets, small-scale simulations, open-source tools, and cloud credits make the problem tractable, though production-scale deployment requires hyperscale resources and expertise.

Agentic AI Top Trend of 2025

The Dapr Agentic Cloud Ascent (DACA) Design Pattern Addresses 10 Million AI Agents Challenge

Let’s understand and learn about “Dapr Agentic Cloud Ascent (DACA)”, our winning design pattern for developing and deploying planet scale multi-agent systems.

Executive Summary: Dapr Agentic Cloud Ascent (DACA)

The Dapr Agentic Cloud Ascent (DACA) guide introduces a strategic design pattern for building and deploying sophisticated, scalable, and resilient agentic AI systems. Addressing the complexities of modern AI development, DACA integrates the OpenAI Agents SDK for core agent logic with the Model Context Protocol (MCP) for standardized tool use and the Agent2Agent (A2A) protocol for seamless inter-agent communication, all underpinned by the distributed capabilities of Dapr. Grounded in AI-first and cloud-first principles, DACA promotes the use of stateless, containerized applications deployed on platforms like Azure Container Apps (Serverless Containers) or Kubernetes, enabling efficient scaling from local development to planetary-scale production, potentially leveraging free-tier cloud services and self-hosted LLMs for cost optimization. The pattern emphasizes modularity, context-awareness, and standardized communication, envisioning an Agentia World where diverse AI agents collaborate intelligently. Ultimately, DACA offers a robust, flexible, and cost-effective framework for developers and architects aiming to create complex, cloud-native agentic AI applications that are built for scalability and resilience from the ground up.

Comprehensive Guide to Dapr Agentic Cloud Ascent (DACA) Design Pattern

Target User

Agentic AI Developer and AgentOps Professionals

Why OpenAI Agents SDK should be the main framework for agentic development for most use cases?

Table 1: Comparison of Abstraction Levels in AI Agent Frameworks

Framework	Abstraction Level	Key Characteristics	Learning Curve	Control Level	Simplicity
OpenAI Agents SDK	Minimal	Python-first, core primitives (Agents, Handoffs, Guardrails), direct control	Low	High	High
CrewAI	Moderate	Role-based agents, crews, tasks, focus on collaboration	Low-Medium	Medium	Medium
AutoGen	High	Conversational agents, flexible conversation patterns, human-in-the-loop support	Medium	Medium	Medium
Google ADK	Moderate	Multi-agent hierarchies, Google Cloud integration (Gemini, Vertex AI), rich tool ecosystem, bidirectional streaming	Medium	Medium-High	Medium
LangGraph	Low-Moderate	Graph-based workflows, nodes, edges, explicit state management	Very High	Very High	Low
Dapr Agents	Moderate	Stateful virtual actors, event-driven multi-agent workflows, Kubernetes integration, 50+ data connectors, built-in resiliency	Medium	Medium-High	Medium

The table clearly identifies why OpenAI Agents SDK should be the main framework for agentic development for most use cases:

It excels in simplicity and ease of use, making it the best choice for rapid development and broad accessibility.
It offers high control with minimal abstraction, providing the flexibility needed for agentic development without the complexity of frameworks like LangGraph.
It outperforms most alternatives (CrewAI, AutoGen, Google ADK, Dapr Agents) in balancing usability and power, and while LangGraph offers more control, its complexity makes it less practical for general use.

If your priority is ease of use, flexibility, and quick iteration in agentic development, OpenAI Agents SDK is the clear winner based on the table. However, if your project requires enterprise-scale features (e.g., Dapr Agents) or maximum control for complex workflows (e.g., LangGraph), you might consider those alternatives despite their added complexity.

Core DACA Agentic AI Courses:

AI-201: Fundamentals of Agentic AI and DACA AI-First Development (14 weeks)

⁠Agentic & DACA Theory - 1 week
UV & ⁠OpenAI Agents SDK - 5 weeks
⁠Agentic Design Patterns - 2 weeks
⁠Memory [LangMem & mem0] 1 week
Postgres/Redis (Managed Cloud) - 1 week
FastAPI (Basic) - 2 weeks
⁠Containerization (Rancher Desktop) - 1 week
Hugging Face Docker Spaces - 1 week

AI-201 Video Playlist

Note: These videos are for additional learning, and do not cover all the material taught in the onsite classes.

Prerequisite: Successful completion of AI-101: Modern AI Python Programming - Your Launchpad into Intelligent Systems

AI-202: DACA Cloud-First Agentic AI Development (14 weeks)

Rancher Desktop with Local Kubernetes - 4 weeks
Advanced FastAPI with Kubernetes - 2 weeks
Dapr [workflows, state, pubsub, secrets] - 3 Week
CockRoachdb & RabbitMQ Managed Services - 2 weeks
⁠Model Context Protocol - 2 weeks
⁠Serverless Containers Deployment (ACA) - 2 weeks

Prerequisite: Successful completion of AI-201

AI-301 DACA Planet-Scale Distributed AI Agents (14 Weeks)

⁠Certified Kubernetes Application Developer (CKAD) - 4 weeks
⁠A2A Protocol - 2 weeks
⁠Voice Agents - 2 weeks
⁠Dapr Agents/Google ADK - 2 weeks
⁠Self-LLMs Hosting - 1 week
Finetuning LLMs - 3 weeks

Prerequisite: Successful completion of AI-201 & AI-202

Evaluations

Quizzes + Hackathons (Everything is Onsite)

Advanced Modern Python (including asyncio) [Q1]
OpenAI Agents SDK (48 MCQ in 2 hour) [01_ai_agents_first]
Protocols & Design Patterns (A2A and MCP) [05_ai_protocols]
Hackathon1 - 8 Hours (Using Above Quiz Stack)
Containerization + FastAPI [05_daca_agent_native_dev = 01 + 02 ]
Kubernetes (Rancher Desktop) [Stimulations] [05_daca_agent_native_dev = 02 ]
Dapr-1 - State, PubSub, Bindings, Invocation [05_daca_agent_native_dev = 03 ]
Dapr-2 - Workflows, Virtual Actors [04_agent_native = 04, 05, 06]
Hackathon2 - 8 Hours (Agent Native Startup)
CKAD + DAPR + ArgoCD (Simulations) [06_daca_deployment_guide + 07_ckad]

Quiz Details

Fundamentals of Agentic AI Quiz

Total Questions: 48 MCQs

Duration: 120 Minutes

Difficulty Level: Intermediate or Advanced (NOT beginner-level)

Quiz Preparation Playlist

This is a well-constructed, comprehensive quiz that accurately tests deep knowledge of the OpenAI Agents SDK. However, it’s significantly more challenging than typical beginner-level assessments.

Difficulty Level for Beginners

The quiz is challenging for beginners due to the following factors:

Technical Depth: Questions require understanding the OpenAI Agents SDK’s architecture (e.g., Agents, Tools, Handoffs, Runner), Pydantic models, async programming, and prompt engineering. These are advanced topics for someone new to AI or Python.
Conceptual Complexity: Topics like dynamic instructions, context management, error handling, and Chain-of-Thought prompting require familiarity with both theoretical and practical aspects of agentic AI.
Code Analysis: Many questions involve analyzing code snippets, understanding execution paths, and predicting outcomes, which demand strong Python and debugging skills. Domain Knowledge: Questions on Markdown are simpler, but the majority focus on niche SDK features, making the quiz specialized.
Beginner Challenges: Beginners (e.g., those with basic Python knowledge and minimal AI experience) would struggle with SDK-specific concepts like Runner.run_sync, tool_choice, and Pydantic validation, as well as async programming and multi-agent workflows.
Difficulty Rating: Advanced (not beginner-friendly). Beginners would need foundational knowledge in Python, async programming, and LLMs, plus specific training on the OpenAI Agents SDK to perform well.

To excel in this quiz, focus on understanding the core components and philosophy of the OpenAI Agents SDK, such as its “Python-first” design for orchestration, the roles of Agents and Tools, and how primitives like “Handoffs” facilitate multi-agent collaboration. Pay close attention to how the SDK manages the agent loop, handles tool calls and Pydantic models for typed inputs/outputs, and uses context objects. Review concepts like dynamic instructions, agent cloning, error handling during tool execution, and the nuances of Runner.run_sync() versus streaming. Additionally, refresh your knowledge of prompt engineering techniques, including crafting clear instructions, guiding the agent’s reasoning (e.g., Chain-of-Thought), and managing sensitive data through persona and careful prompting. Finally, ensure you’re comfortable with basic Markdown syntax for links and images.

Preparation Guide for Beginner Students

This OpenAI Agents SDK quiz is designed for intermediate to advanced learners and requires substantial preparation to succeed. Before attempting this assessment, ensure you have a solid foundation in Python programming, including object-oriented concepts, async/await patterns, decorators, and error handling. You’ll need to thoroughly study Pydantic models for data validation, understanding field definitions, default values, and validation behavior. Dedicate significant time to the OpenAI Agents SDK documentation (https://openai.github.io/openai-agents-python/), focusing on core concepts like Agents, Tools, Handoffs, context management, and the agent execution loop. Practice writing and analyzing code that uses the @function_tool decorator, Runner.run_sync(), agent cloning, and multi-agent orchestration patterns. Review prompt engineering techniques from the OpenAI cookbook, particularly Chain-of-Thought prompting, system message design, and handling sensitive data. Finally, familiarize yourself with basic Markdown syntax for links and images. Plan to spend at least 2-3 weeks studying these materials, complete hands-on coding exercises with the SDK. Consider this quiz a capstone assessment that requires comprehensive understanding rather than a beginner-level introduction to the concepts.

Quiz Covers:

https://openai.github.io/openai-agents-python/

https://cookbook.openai.com/examples/gpt4-1_prompting_guide

https://www.markdownguide.org/basic-syntax/

https://www.markdownguide.org/cheat-sheet/

https://github.com/panaversity/learn-agentic-ai/tree/main/01_ai_agents_first

You Can Generate Mock Quizzes for Practice using LLMs from this Prompt:

Create a comprehensive quiz covering OpenAI Agents SDK. It should include as many MCQ Quiz Questions as required to test the material, the questions should be difficult and at the graduate level and should test both concepts and include code were required. From the following following documentation:

https://openai.github.io/openai-agents-python/

kubernetes-the-hard-way

Mon, 09 Jun 2025 15:31:41 +0800

kelseyhightower/kubernetes-the-hard-way

Kubernetes The Hard Way

This tutorial walks you through setting up Kubernetes the hard way. This guide is not for someone looking for a fully automated tool to bring up a Kubernetes cluster. Kubernetes The Hard Way is optimized for learning, which means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster.

The results of this tutorial should not be viewed as production ready, and may receive limited support from the community, but don’t let that stop you from learning!

Copyright

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Target Audience

The target audience for this tutorial is someone who wants to understand the fundamentals of Kubernetes and how the core components fit together.

Cluster Details

Kubernetes The Hard Way guides you through bootstrapping a basic Kubernetes cluster with all control plane components running on a single node, and two worker nodes, which is enough to learn the core concepts.

Component versions:

kubernetes v1.32.x
containerd v2.1.x
cni v1.6.x
etcd v3.6.x

Labs

This tutorial requires four (4) ARM64 or AMD64 based virtual or physical machines connected to the same network.

kubectl-ai

Sat, 10 May 2025 15:25:23 +0800

GoogleCloudPlatform/kubectl-ai

kubectl-ai

kubectl-ai acts as an intelligent interface, translating user intent into precise Kubernetes operations, making Kubernetes management more accessible and efficient.

Quick Start

First, ensure that kubectl is installed and configured.

Installation

Quick Install (Linux & MacOS only)

`1`	`curl -sSL https://raw.githubusercontent.com/GoogleCloudPlatform/kubectl-ai/main/install.sh \| bash`

Manual Installation (Linux, MacOS and Windows)

Download the latest release from the releases page for your target machine.
Untar the release, make the binary executable and move it to a directory in your $PATH (as shown below).

1
2
3

tar -zxvf kubectl-ai_Darwin_arm64.tar.gz
chmod a+x kubectl-ai
sudo mv kubectl-ai /usr/local/bin/

Install with Krew (Linux/macOS/Windows)

First of all, you need to have krew insatlled, refer to krew document for more details Then you can install with krew

`1`	`kubectl krew install ai`

Now you can invoke kubectl-ai as a kubectl plugin like this: kubectl ai.

Usage

Using Gemini (Default)

Set your Gemini API key as an environment variable. If you don’t have a key, get one from Google AI Studio.

export GEMINI_API_KEY=your_api_key_here
kubectl-ai

# Use different gemini model
kubectl-ai --model gemini-2.5-pro-exp-03-25

# Use 2.5 flash (faster) model
kubectl-ai --quiet --model gemini-2.5-flash-preview-04-17 "check logs for nginx app in hello namespace"

Using AI models running locally (ollama or llama.cpp)

You can use kubectl-ai with AI models running locally. kubectl-ai supports ollama and llama.cpp to use the AI models running locally.

An example of using Google’s gemma3 model with ollama:

# assuming ollama is already running and you have pulled one of the gemma models
# ollama pull gemma3:12b-it-qat

# if your ollama server is at remote, use OLLAMA_HOST variable to specify the host
# export OLLAMA_HOST=http://192.168.1.3:11434/

# enable-tool-use-shim because models require special prompting to enable tool calling
kubectl-ai --llm-provider ollama --model gemma3:12b-it-qat --enable-tool-use-shim

# you can use `models` command to discover the locally available models
>> models

Using Grok

You can use X.AI’s Grok model by setting your X.AI API key:

1
2

export GROK_API_KEY=your_xai_api_key_here
kubectl-ai --llm-provider=grok --model=grok-3-beta

Using Azure OpenAI

You can also use Azure OpenAI deployment by setting your OpenAI API key and specifying the provider:

export AZURE_OPENAI_API_KEY=your_azure_openai_api_key_here
export AZURE_OPENAI_ENDPOINT=https://your_azure_openai_endpoint_here
kubectl-ai --llm-provider=azopenai --model=your_azure_openai_deployment_name_here
# or
az login
kubectl-ai --llm-provider=openai://your_azure_openai_endpoint_here --model=your_azure_openai_deployment_name_here

Using OpenAI

You can also use OpenAI models by setting your OpenAI API key and specifying the provider:

1
2

export OPENAI_API_KEY=your_openai_api_key_here
kubectl-ai --llm-provider=openai --model=gpt-4.1

Using OpenAI Compatible API

For example, you can use aliyun qwen-xxx models as follows

1
2
3

export OPENAI_API_KEY=your_openai_api_key_here
export OPENAI_ENDPOINT=https://dashscope.aliyuncs.com/compatible-mode/v1
kubectl-ai --llm-provider=openai --model=qwen-plus

Note: kubectl-ai supports AI models from gemini, vertexai, azopenai, openai, grok and local LLM providers such as ollama and llama.cpp.

Run interactively:

`1`	`kubectl-ai`

The interactive mode allows you to have a chat with kubectl-ai, asking multiple questions in sequence while maintaining context from previous interactions. Simply type your queries and press Enter to receive responses. To exit the interactive shell, type exit or press Ctrl+C.

Or, run with a task as input:

`1`	`kubectl-ai --quiet "fetch logs for nginx app in hello namespace"`

Combine it with other unix commands:

1
2
3

kubectl-ai < query.txt
# OR
echo "list pods in the default namespace" | kubectl-ai

You can even combine a positional argument with stdin input. The positional argument will be used as a prefix to the stdin content:

`1`	`cat error.log \| kubectl-ai "explain the error"`

Extras

You can use the following special keywords for specific actions:

model: Display the currently selected model.
models: List all available models.
version: Display the kubectl-ai version.
reset: Clear the conversational context.
clear: Clear the terminal screen.
exit or quit: Terminate the interactive shell (Ctrl+C also works).

Invoking as kubectl plugin

Use it via the kubectl plug interface like this: kubectl ai. kubectl will find kubectl-ai as long as it’s in your PATH. For more information about plugins please see: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/

Examples

# Get information about pods in the default namespace
kubectl-ai --quiet "show me all pods in the default namespace"

# Create a new deployment
kubectl-ai --quiet "create a deployment named nginx with 3 replicas using the nginx:latest image"

# Troubleshoot issues
kubectl-ai --quiet "double the capacity for the nginx app"

# Using Azure OpenAI instead of Gemini
kubectl-ai --llm-provider=azopenai --model=your_azure_openai_deployment_name_here --quiet "scale the nginx deployment to 5 replicas"

# Using OpenAI instead of Gemini
kubectl-ai --llm-provider=openai --model=gpt-4.1 --quiet "scale the nginx deployment to 5 replicas"

The kubectl-ai will process your query, execute the appropriate kubectl commands, and provide you with the results and explanations.

MCP server

You can also use kubectl-ai as a MCP server that exposes kubectl as one of the tools to interact with locally configured k8s environment. See mcp docs for more details.

k8s-bench

kubectl-ai project includes k8s-bench - a benchmark to evaluate performance of different LLM models on kubernetes related tasks. Here is a summary from our last run:

Model	Success	Fail
gemini-2.5-flash-preview-04-17	10	0
gemini-2.5-pro-preview-03-25	10	0
gemma-3-27b-it	8	2
Total	28	2

See full report for more details.

Start Contributing

We welcome contributions to kubectl-ai from the community. Take a look at our contribution guide to get started.

Note: This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program.

containerd

Wed, 07 May 2025 15:29:36 +0800

containerd/containerd

containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

containerd is a member of CNCF with ‘graduated’ status.

containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users.

Announcements

containerd v2.0 is now released!

See docs/containerd-2.0.md.

Now Recruiting

We are a large inclusive OSS project that is welcoming help of any kind shape or form:

Documentation help is needed to make the product easier to consume and extend.
We need OSS community outreach/organizing help to get the word out; manage and create messaging and educational content; and help with social media, community forums/groups, and google groups.
We are actively inviting new security advisors to join the team.
New subprojects are being created, core and non-core that could use additional development help.
Each of the containerd projects has a list of issues currently being worked on or that need help resolving.
- If the issue has not already been assigned to someone or has not made recent progress, and you are interested, please inquire.
- If you are interested in starting with a smaller/beginner-level issue, look for issues with an exp/beginner tag, for example containerd/containerd beginner issues.

Getting Started

See our documentation on containerd.io:

To get started contributing to containerd, see CONTRIBUTING.

If you are interested in trying out containerd see our example at Getting Started.

Nightly builds

There are nightly builds available for download here. Binaries are generated from main branch every night for Linux and Windows.

Please be aware: nightly builds might have critical bugs, it’s not recommended for use in production and no support provided.

Kubernetes (k8s) CI Dashboard Group

The k8s CI dashboard group for containerd contains test results regarding the health of kubernetes when run against main and a number of containerd release branches.

containerd-periodics

Runtime Requirements

Runtime requirements for containerd are very minimal. Most interactions with the Linux and Windows container feature sets are handled via runc and/or OS-specific libraries (e.g. hcsshim for Microsoft). The current required version of runc is described in RUNC.md.

There are specific features used by containerd core code and snapshotters that will require a minimum kernel version on Linux. With the understood caveat of distro kernel versioning, a reasonable starting point for Linux is a minimum 4.x kernel version.

The overlay filesystem snapshotter, used by default, uses features that were finalized in the 4.x kernel series. If you choose to use btrfs, there may be more flexibility in kernel version (minimum recommended is 3.18), but will require the btrfs kernel module and btrfs tools to be installed on your Linux distribution.

To use Linux checkpoint and restore features, you will need criu installed on your system. See more details in Checkpoint and Restore.

Build requirements for developers are listed in BUILDING.

Supported Registries

Any registry which is compliant with the OCI Distribution Specification is supported by containerd.

For configuring registries, see registry host configuration documentation

Features

For a detailed overview of containerd’s core concepts and the features it supports, please refer to the FEATURES.MD document.

Releases and API Stability

Please see RELEASES.md for details on versioning and stability of containerd components.

Downloadable 64-bit Intel/AMD binaries of all official releases are available on our releases page.

For other architectures and distribution support, you will find that many Linux distributions package their own containerd and provide it across several architectures, such as Canonical’s Ubuntu packaging.

Enabling command auto-completion

Starting with containerd 1.4, the urfave client feature for auto-creation of bash and zsh autocompletion data is enabled. To use the autocomplete feature in a bash shell for example, source the autocomplete/ctr file in your .bashrc, or manually like:

`1`	`$ source ./contrib/autocomplete/ctr`

Distribution of `ctr` autocomplete for bash and zsh

For bash, copy the contrib/autocomplete/ctr script into /etc/bash_completion.d/ and rename it to ctr. The zsh_autocomplete file is also available and can be used similarly for zsh users.

Provide documentation to users to source this file into their shell if you don’t place the autocomplete file in a location where it is automatically loaded for the user’s shell environment.

CRI

cri is a containerd plugin implementation of the Kubernetes container runtime interface (CRI). With it, you are able to use containerd as the container runtime for a Kubernetes cluster.

CRI Status

cri is a native plugin of containerd. Since containerd 1.1, the cri plugin is built into the release binaries and enabled by default.

The cri plugin has reached GA status, representing that it is:

Feature complete
Works with Kubernetes 1.10 and above
Passes all CRI validation tests.
Passes all node e2e tests.
Passes all e2e tests.

See results on the containerd k8s test dashboard

Validating Your `cri` Setup

A Kubernetes incubator project, cri-tools, includes programs for exercising CRI implementations. More importantly, cri-tools includes the program critest which is used for running CRI Validation Testing.

CRI Guides

Communication

For async communication and long-running discussions please use issues and pull requests on the GitHub repo. This will be the best place to discuss design and implementation.

For sync communication catch us in the #containerd and #containerd-dev Slack channels on Cloud Native Computing Foundation’s (CNCF) Slack - cloud-native.slack.com. Everyone is welcome to join and chat. Get Invite to CNCF Slack.

Join our next community meeting hosted on Zoom. The schedule is posted on the CNCF Calendar (search ‘containerd’ to filter).

Security audit

Security audits for the containerd project are hosted on our website. Please see the security page at containerd.io for more information.

Reporting security issues

Please follow the instructions at containerd/project

Licenses

The containerd codebase is released under the Apache 2.0 license. The README.md file and files in the “docs” folder are licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.

Project details

containerd is the primary open source project within the broader containerd GitHub organization. However, all projects within the repo have common maintainership, governance, and contributing guidelines which are stored in a project repository commonly for all containerd projects.

Please find all these core project documents, including the:

information in our containerd/project repository.

Adoption

Interested to see who is using containerd? Are you using containerd in a project? Please add yourself via pull request to our ADOPTERS.md file.

open-webui

Sat, 03 May 2025 15:27:20 +0800

open-webui/open-webui

Open WebUI 👋

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform designed to operate entirely offline. It supports various LLM runners like Ollama and OpenAI-compatible APIs, with built-in inference engine for RAG, making it a powerful AI deployment solution.

[!TIP]
Looking for an Enterprise Plan? – Speak with Our Sales Team Today!

Get enhanced capabilities, including custom theming and branding, Service Level Agreement (SLA) support, Long-Term Support (LTS) versions, and more!

For more information, be sure to check out our Open WebUI Documentation.

Key Features of Open WebUI ⭐

🚀 Effortless Setup: Install seamlessly using Docker or Kubernetes (kubectl, kustomize or helm) for a hassle-free experience with support for both :ollama and :cuda tagged images.
🤝 Ollama/OpenAI API Integration: Effortlessly integrate OpenAI-compatible APIs for versatile conversations alongside Ollama models. Customize the OpenAI API URL to link with LMStudio, GroqCloud, Mistral, OpenRouter, and more.
🛡️ Granular Permissions and User Groups: By allowing administrators to create detailed user roles and permissions, we ensure a secure user environment. This granularity not only enhances security but also allows for customized user experiences, fostering a sense of ownership and responsibility amongst users.
📱 Responsive Design: Enjoy a seamless experience across Desktop PC, Laptop, and Mobile devices.
📱 Progressive Web App (PWA) for Mobile: Enjoy a native app-like experience on your mobile device with our PWA, providing offline access on localhost and a seamless user interface.
✒️🔢 Full Markdown and LaTeX Support: Elevate your LLM experience with comprehensive Markdown and LaTeX capabilities for enriched interaction.
🎤📹 Hands-Free Voice/Video Call: Experience seamless communication with integrated hands-free voice and video call features, allowing for a more dynamic and interactive chat environment.
🛠️ Model Builder: Easily create Ollama models via the Web UI. Create and add custom characters/agents, customize chat elements, and import models effortlessly through Open WebUI Community integration.
🐍 Native Python Function Calling Tool: Enhance your LLMs with built-in code editor support in the tools workspace. Bring Your Own Function (BYOF) by simply adding your pure Python functions, enabling seamless integration with LLMs.
📚 Local RAG Integration: Dive into the future of chat interactions with groundbreaking Retrieval Augmented Generation (RAG) support. This feature seamlessly integrates document interactions into your chat experience. You can load documents directly into the chat or add files to your document library, effortlessly accessing them using the # command before a query.
🔍 Web Search for RAG: Perform web searches using providers like SearXNG, Google PSE, Brave Search, serpstack, serper, Serply, DuckDuckGo, TavilySearch, SearchApi and Bing and inject the results directly into your chat experience.
🌐 Web Browsing Capability: Seamlessly integrate websites into your chat experience using the # command followed by a URL. This feature allows you to incorporate web content directly into your conversations, enhancing the richness and depth of your interactions.
🎨 Image Generation Integration: Seamlessly incorporate image generation capabilities using options such as AUTOMATIC1111 API or ComfyUI (local), and OpenAI’s DALL-E (external), enriching your chat experience with dynamic visual content.
⚙️ Many Models Conversations: Effortlessly engage with various models simultaneously, harnessing their unique strengths for optimal responses. Enhance your experience by leveraging a diverse set of models in parallel.
🔐 Role-Based Access Control (RBAC): Ensure secure access with restricted permissions; only authorized individuals can access your Ollama, and exclusive model creation/pulling rights are reserved for administrators.
🌐🌍 Multilingual Support: Experience Open WebUI in your preferred language with our internationalization (i18n) support. Join us in expanding our supported languages! We’re actively seeking contributors!
🧩 Pipelines, Open WebUI Plugin Support: Seamlessly integrate custom logic and Python libraries into Open WebUI using Pipelines Plugin Framework. Launch your Pipelines instance, set the OpenAI URL to the Pipelines URL, and explore endless possibilities. Examples include Function Calling, User Rate Limiting to control access, Usage Monitoring with tools like Langfuse, Live Translation with LibreTranslate for multilingual support, Toxic Message Filtering and much more.
🌟 Continuous Updates: We are committed to improving Open WebUI with regular updates, fixes, and new features.

Want to learn more about Open WebUI’s features? Check out our Open WebUI documentation for a comprehensive overview!

🔗 Also Check Out Open WebUI Community!

Don’t forget to explore our sibling project, Open WebUI Community, where you can discover, download, and explore customized Modelfiles. Open WebUI Community offers a wide range of exciting possibilities for enhancing your chat interactions with Open WebUI! 🚀

How to Install 🚀

Installation via Python pip 🐍

Open WebUI can be installed using pip, the Python package installer. Before proceeding, ensure you’re using Python 3.11 to avoid compatibility issues.

Install Open WebUI: Open your terminal and run the following command to install Open WebUI:
1

pip install open-webui
Running Open WebUI: After installation, you can start Open WebUI by executing:
1

open-webui serve

This will start the Open WebUI server, which you can access at http://localhost:8080

Quick Start with Docker 🐳

[!NOTE]
Please note that for certain Docker environments, additional configurations might be needed. If you encounter any connection issues, our detailed guide on Open WebUI Documentation is ready to assist you.

[!WARNING] When using Docker to install Open WebUI, make sure to include the -v open-webui:/app/backend/data in your Docker command. This step is crucial as it ensures your database is properly mounted and prevents any loss of data.

[!TIP]
If you wish to utilize Open WebUI with Ollama included or CUDA acceleration, we recommend utilizing our official images tagged with either :cuda or :ollama. To enable CUDA, you must install the Nvidia CUDA container toolkit on your Linux/WSL system.

Installation with Default Configuration

If Ollama is on your computer, use this command:

`1`	`docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

If Ollama is on a Different Server, use this command:

To connect to Ollama on another server, change the OLLAMA_BASE_URL to the server’s URL:

`1`	`docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

To run Open WebUI with Nvidia GPU support, use this command:

`1`	`docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda`

Installation for OpenAI API Usage Only

If you’re only using OpenAI API, use this command:

`1`	`docker run -d -p 3000:8080 -e OPENAI_API_KEY=your_secret_key -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

Installing Open WebUI with Bundled Ollama Support

This installation method uses a single container image that bundles Open WebUI with Ollama, allowing for a streamlined setup via a single command. Choose the appropriate command based on your hardware setup:

With GPU Support: Utilize GPU resources by running the following command:

`1`	`docker run -d -p 3000:8080 --gpus=all -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama`

For CPU Only: If you’re not using a GPU, use this command instead:

`1`	`docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama`

Both commands facilitate a built-in, hassle-free installation of both Open WebUI and Ollama, ensuring that you can get everything up and running swiftly.

After installation, you can access Open WebUI at http://localhost:3000. Enjoy! 😄

Other Installation Methods

We offer various installation alternatives, including non-Docker native installation methods, Docker Compose, Kustomize, and Helm. Visit our Open WebUI Documentation or join our Discord community for comprehensive guidance.

Troubleshooting

Encountering connection issues? Our Open WebUI Documentation has got you covered. For further assistance and to join our vibrant community, visit the Open WebUI Discord.

Open WebUI: Server Connection Error

If you’re experiencing connection issues, it’s often due to the WebUI docker container not being able to reach the Ollama server at 127.0.0.1:11434 (host.docker.internal:11434) inside the container . Use the --network=host flag in your docker command to resolve this. Note that the port changes from 3000 to 8080, resulting in the link: http://localhost:8080.

Example Docker Command:

`1`	`docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

Keeping Your Docker Installation Up-to-Date

In case you want to update your local Docker installation to the latest version, you can do it with Watchtower:

`1`	`docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --run-once open-webui`

In the last part of the command, replace open-webui with your container name if it is different.

Check our Updating Guide available in our Open WebUI Documentation.

Using the Dev Branch 🌙

[!WARNING] The :dev branch contains the latest unstable features and changes. Use it at your own risk as it may have bugs or incomplete features.

If you want to try out the latest bleeding-edge features and are okay with occasional instability, you can use the :dev tag like this:

`1`	`docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui --add-host=host.docker.internal:host-gateway --restart always ghcr.io/open-webui/open-webui:dev`

Offline Mode

If you are running Open WebUI in an offline environment, you can set the HF_HUB_OFFLINE environment variable to 1 to prevent attempts to download models from the internet.

`1`	`export HF_HUB_OFFLINE=1`

What’s Next? 🌟

Discover upcoming features on our roadmap in the Open WebUI Documentation.

License 📜

This project is licensed under the BSD-3-Clause License - see the LICENSE file for details. 📄

Support 💬

If you have any questions, suggestions, or need assistance, please open an issue or join our Open WebUI Discord community to connect with us! 🤝

Star History

Created by Timothy Jaeryang Baek - Let’s make Open WebUI even more amazing together! 💪

skypilot

Sun, 27 Apr 2025 15:27:09 +0800

skypilot-org/skypilot

Run AI on Any Infra — Unified, Faster, Cheaper

:fire: News :fire:

[Mar 2025] Run and serve Google Gemma 3 using SkyPilot example
[Feb 2025] Prepare and serve Retrieval Augmented Generation (RAG) with DeepSeek-R1: blog post, example
[Feb 2025] Run and serve DeepSeek-R1 671B using SkyPilot and SGLang with high throughput: example
[Feb 2025] Prepare and serve large-scale image search with vector databases: blog post, example
[Jan 2025] Launch and serve distilled models from DeepSeek-R1 and Janus on Kubernetes or any cloud: R1 example and Janus example
[Oct 2024] :tada: SkyPilot crossed 1M+ downloads :tada:: Thank you to our community! Twitter/X
[Sep 2024] Point, launch and serve Llama 3.2 on Kubernetes or any cloud: example
[Sep 2024] Run and deploy Pixtral, the first open-source multimodal model from Mistral AI.
[Jun 2024] Reproduce GPT with llm.c on any cloud: guide
[Apr 2024] Serve Qwen-110B on your infra: example
[Apr 2024] Host Ollama on the cloud to deploy LLMs on CPUs and GPUs: example

LLM Finetuning Cookbooks: Finetuning Llama 2 / Llama 3.1 in your own cloud environment, privately: Llama 2 example and blog; Llama 3.1 example and blog

SkyPilot is an open-source framework for running AI and batch workloads on any infra.

SkyPilot is easy to use for AI users:

Quickly spin up compute on your own infra
Environment and job as code — simple and portable
Easy job management: queue, run, and auto-recover many jobs

SkyPilot unifies multiple clusters, clouds, and hardware:

One interface to use reserved GPUs, Kubernetes clusters, or 16+ clouds
Flexible provisioning of GPUs, TPUs, CPUs, with auto-retry
Team deployment and resource sharing

SkyPilot cuts your cloud costs & maximizes GPU availability:

Autostop: automatic cleanup of idle resources
Spot instance support: 3-6x cost savings, with preemption auto-recovery
Intelligent scheduling: automatically run on the cheapest & most available infra

SkyPilot supports your existing GPU, TPU, and CPU workloads, with no code changes.

Install with pip:

1
2

# Choose your clouds:
pip install -U "skypilot[kubernetes,aws,gcp,azure,oci,lambda,runpod,fluidstack,paperspace,cudo,ibm,scp,nebius]"

To get the latest features and fixes, use the nightly build or install from source:

1
2

# Choose your clouds:
pip install "skypilot-nightly[kubernetes,aws,gcp,azure,oci,lambda,runpod,fluidstack,paperspace,cudo,ibm,scp,nebius]"

Current supported infra: Kubernetes, AWS, GCP, Azure, OCI, Lambda Cloud, Fluidstack, RunPod, Cudo, Digital Ocean, Paperspace, Cloudflare, Samsung, IBM, Vast.ai, VMware vSphere, Nebius.

Getting started

You can find our documentation here.

SkyPilot in 1 minute

A SkyPilot task specifies: resource requirements, data to be synced, setup commands, and the task commands.

Once written in this unified interface (YAML or Python API), the task can be launched on any available cloud. This avoids vendor lock-in, and allows easily moving jobs to a different provider.

Paste the following into a file my_task.yaml:

resources:
  accelerators: A100:8  # 8x NVIDIA A100 GPU

num_nodes: 1  # Number of VMs to launch

# Working directory (optional) containing the project codebase.
# Its contents are synced to ~/sky_workdir/ on the cluster.
workdir: ~/torch_examples

# Commands to be run before executing the job.
# Typical use: pip install -r requirements.txt, git clone, etc.
setup: |
  pip install "torch<2.2" torchvision --index-url https://download.pytorch.org/whl/cu121

# Commands to run as a job.
# Typical use: launch the main program.
run: |
  cd mnist
  python main.py --epochs 1

Prepare the workdir by cloning:

`1`	`git clone https://github.com/pytorch/examples.git ~/torch_examples`

Launch with sky launch (note: access to GPU instances is needed for this example):

`1`	`sky launch my_task.yaml`

SkyPilot then performs the heavy-lifting for you, including:

Find the lowest priced VM instance type across different clouds
Provision the VM, with auto-failover if the cloud returned capacity errors
Sync the local workdir to the VM
Run the task’s setup commands to prepare the VM for running the task
Run the task’s run commands

See Quickstart to get started with SkyPilot.

Runnable examples

See SkyPilot examples that cover: development, training, serving, LLM models, AI apps, and common frameworks.

Latest featured examples:

Task	Examples
Training	PyTorch, DeepSpeed, Finetune Llama 3, NeMo, Ray, Unsloth, Jax/TPU
Serving	vLLM, SGLang, Ollama
Models	DeepSeek-R1, Llama 3, CodeLlama, Qwen, Mixtral
AI apps	RAG, vector databases (ChromaDB, CLIP)
Common frameworks	Airflow, Jupyter

Source files and more examples can be found in llm/ and examples/.

More information

To learn more, see SkyPilot Overview, SkyPilot docs, and SkyPilot blog.

Case studies and integrations: Community Spotlights

Follow updates:

Read the research:

SkyPilot paper and talk (NSDI 2023)
Sky Computing whitepaper
Sky Computing vision paper (HotOS 2021)
SkyServe: AI serving across regions and clouds (EuroSys 2025)
Managed jobs spot instance policy (NSDI 2024)

SkyPilot was initially started at the Sky Computing Lab at UC Berkeley and has since gained many industry contributors. To read about the project’s origin and vision, see Concept: Sky Computing.

Questions and feedback

We are excited to hear your feedback:

For issues and feature requests, please open a GitHub issue.
For questions, please use GitHub Discussions.

For general discussions, join us on the SkyPilot Slack.

Contributing

We welcome all contributions to the project! See CONTRIBUTING for how to get involved.

jumpserver

Tue, 22 Apr 2025 15:29:56 +0800

jumpserver/jumpserver

An open-source PAM tool (Bastion Host)

English · 中文(简体) · 中文(繁體) · 日本語 · Português (Brasil) · Español · Русский

What is JumpServer?

JumpServer is an open-source Privileged Access Management (PAM) tool that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.

Quickstart

Prepare a clean Linux Server ( 64 bit, >= 4c8g )

`1`	`curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh \| bash`

Access JumpServer in your browser at http://your-jumpserver-ip/

Username: admin
Password: ChangeMe

Screenshots

Components

JumpServer consists of multiple key components, which collectively form the functional framework of JumpServer, providing users with comprehensive capabilities for operations management and security control.

Project	Status	Description
Lina		JumpServer Web UI
Luna		JumpServer Web Terminal
KoKo		JumpServer Character Protocol Connector
Lion		JumpServer Graphical Protocol Connector
Chen		JumpServer Web DB
Tinker		JumpServer Remote Application Connector (Windows)
Panda		JumpServer EE Remote Application Connector (Linux)
Razor		JumpServer EE RDP Proxy Connector
Magnus		JumpServer EE Database Proxy Connector
Nec		JumpServer EE VNC Proxy Connector
Facelive		JumpServer EE Facial Recognition

Contributing

Welcome to submit PR to contribute. Please refer to CONTRIBUTING.md for guidelines.

License

Licensed under The GNU General Public License version 3 (GPLv3) (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

https://www.gnu.org/licenses/gpl-3.0.html

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an " AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

gofr

Wed, 16 Apr 2025 15:29:42 +0800

gofr-dev/gofr

GoFr

GoFr: An Opinionated Microservice Development Framework

Listed in the CNCF Landscape

🎯 Goal

GoFr is designed to simplify microservice development, with key focuses on Kubernetes deployment and out-of-the-box observability. While capable of building generic applications, microservices remain at its core.

💡 Key Features

Simple API Syntax
REST Standards by Default
Configuration Management
Observability (Logs, Traces, Metrics)
Inbuilt Auth Middleware & Custom Middleware Support
gRPC Support
HTTP Service with Circuit Breaker Support
Pub/Sub
Health Check for All Datasources
Database Migration
Cron Jobs
Support for Changing Log Level Without Restarting
Swagger Rendering
Abstracted File Systems
Websockets

🚀 Getting Started

Prerequisites

GoFr requires Go version 1.21 or above.

Installation

To get started with GoFr, add the following import to your code and use Go’s module support to automatically fetch dependencies:

`1`	`import "gofr.dev/pkg/gofr"`

Alternatively, use the command:

`1`	`go get -u gofr.dev/pkg/gofr`

🏃 Running GoFr

Here’s a simple example to get a GoFr application up and running:

package main

import "gofr.dev/pkg/gofr"

func main() {
	app := gofr.New()

	app.GET("/greet", func(ctx *gofr.Context) (any, error) {
		return "Hello World!", nil
	})

	app.Run() // listens and serves on localhost:8000
}

To run this code:

`1`	`$ go run main.go`

Visit localhost:8000/greet to see the result.

📂 More Examples

Explore a variety of ready-to-run examples in the GoFr examples directory.

👩‍💻 Documentation

GoDoc: Official API documentation.
GoFr Documentation: Comprehensive guides and resources.

👍 Contribute

Help us make GoFr even better:

Star this repo on GitHub! 🌟
Write a review or tutorial on Medium, Dev.to, or your blog.
Review the CONTRIBUTING.md guide to learn how to contribute to the project.

🔒 Secure Cloning

To securely clone the GoFr repository, you can use HTTPS or SSH:

Cloning with HTTPS

`1`	`git clone https://github.com/gofr-dev/gofr.git`

Cloning with SSH

`1`	`git clone git@github.com:gofr-dev/gofr.git`

🎁 Get a GoFr T-Shirt & Stickers!

If your PR is merged, or if you contribute by writing articles or promoting GoFr, we invite you to fill out this form to claim your GoFr merchandise as a token of our appreciation!

Partners

headlamp

Sun, 06 Apr 2025 15:25:35 +0800

kubernetes-sigs/headlamp

NOTICE: We have recently moved the project under the Kubernetes SIG UI (and the repo under the kubernetes-sigs org). Container images are still at ghcr.io. Please bear with us while we may experience some broken links.

Headlamp is an easy-to-use and extensible Kubernetes web UI.

Headlamp was created to blend the traditional feature set of other web UIs/dashboards (i.e., to list and view resources) with added functionality.

Features

Vendor-independent / generic Kubernetes UI
Works in-cluster, or locally as a desktop app
Multi-cluster
Extensible through plugins
UI controls reflecting user roles (no deletion/update if not allowed)
Clean & modern UI
Cancellable creation/update/deletion operations
Logs, exec, and resource editor with documentation
Read-write / interactive (actions based on permissions)

Screenshots

Quickstart

If you want to deploy Headlamp in your cluster, check out the instructions on running it in-cluster.

If you have a kubeconfig already, you can quickly try Headlamp locally as a desktop application for Linux, Mac, or Windows. Make sure you have a kubeconfig file set up with your favorite clusters and in the default path so Headlamp can use it.

Accessing

Headlamp uses RBAC for checking users’ access to resources. If you try Headlamp with a token that has very limited permissions, you may not be able to view your cluster resources correctly.

See the documentation on how to easily get a Service Account token for your cluster.

Tested platforms

We maintain a list of the Kubernetes platforms we have tested Headlamp with. We invite you to add any missing platforms you have tested, or comment if there are any regressions in the existing ones.

Extensions / Plugins

If you are interested in tweaking Headlamp to fit your use-cases, you can check out our plugin development guide.

Get involved

Check out our:

Guidelines
Code of Conduct,
#headlamp slack channel in the Kubernetes Slack
Monthly Community Meeting

Roadmap / Release Planning

If you are interested in the direction of the project, we maintain a Roadmap. It has the biggest changes planned so far, as well as a board tracking each release.

License

Headlamp is released under the terms of the Apache 2.0 license.

Frequently Asked Questions

For more information about Headlamp, see the Headlamp FAQ.

higress

Sat, 05 Apr 2025 15:25:11 +0800

alibaba/higress

AI Gateway

AI Native API Gateway

Official Site | MCP Server QuickStart | Wasm Plugin Hub |

English | 中文 | 日本語

Higress is a cloud-native API gateway based on Istio and Envoy, which can be extended with Wasm plugins written in Go/Rust/JS. It provides dozens of ready-to-use general-purpose plugins and an out-of-the-box console (try the demo here).

Higress was born within Alibaba to solve the issues of Tengine reload affecting long-connection services and insufficient load balancing capabilities for gRPC/Dubbo.

Alibaba Cloud has built its cloud-native API gateway product based on Higress, providing 99.99% gateway high availability guarantee service capabilities for a large number of enterprise customers.

Higress’s AI gateway capabilities support all mainstream model providers both domestic and international, as well as self-built DeepSeek models based on vllm/ollama. Within Alibaba Cloud, it supports AI businesses such as Tongyi Qianwen APP, Bailian large model API, and machine learning PAI platform. It also serves leading AIGC enterprises (such as Zero One Infinite) and AI products (such as FastGPT).

Summary

Quick Start

Higress can be started with just Docker, making it convenient for individual developers to set up locally for learning or for building simple sites:

# Create a working directory
mkdir higress; cd higress
# Start higress, configuration files will be written to the working directory
docker run -d --rm --name higress-ai -v ${PWD}:/data \
        -p 8001:8001 -p 8080:8080 -p 8443:8443  \
        higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/all-in-one:latest

Port descriptions:

Port 8001: Higress UI console entry
Port 8080: Gateway HTTP protocol entry
Port 8443: Gateway HTTPS protocol entry

All Higress Docker images use their own dedicated repository, unaffected by Docker Hub access restrictions in certain regions

For other installation methods such as Helm deployment under K8s, please refer to the official Quick Start documentation.

Use Cases

AI Gateway:

Higress can connect to all LLM model providers both domestic and international using a unified protocol, while also providing rich AI observability, multi-model load balancing/fallback, AI token rate limiting, AI caching, and other capabilities:
MCP Server Hosting:

Higress, as an Envoy-based API gateway, supports hosting MCP Servers through its plugin mechanism. MCP (Model Context Protocol) is essentially an AI-friendly API that enables AI Agents to more easily call various tools and services. Higress provides unified capabilities for authentication, authorization, rate limiting, and observability for tool calls, simplifying the development and deployment of AI applications.

By hosting MCP Servers with Higress, you can achieve:
- Unified authentication and authorization mechanisms, ensuring the security of AI tool calls
- Fine-grained rate limiting to prevent abuse and resource exhaustion
- Comprehensive audit logs recording all tool call behaviors
- Rich observability for monitoring the performance and health of tool calls
- Simplified deployment and management through Higress’s plugin mechanism for quickly adding new MCP Servers
- Dynamic updates without disruption: Thanks to Envoy’s friendly handling of long connections and Wasm plugin’s dynamic update mechanism, MCP Server logic can be updated on-the-fly without any traffic disruption or connection drops
Kubernetes ingress controller:

Higress can function as a feature-rich ingress controller, which is compatible with many annotations of K8s’ nginx ingress controller.

Gateway API support is coming soon and will support smooth migration from Ingress API to Gateway API.
Microservice gateway:

Higress can function as a microservice gateway, which can discovery microservices from various service registries, such as Nacos, ZooKeeper, Consul, Eureka, etc.

It deeply integrates with Dubbo, Nacos, Sentinel and other microservice technology stacks.
Security gateway:

Higress can be used as a security gateway, supporting WAF and various authentication strategies, such as key-auth, hmac-auth, jwt-auth, basic-auth, oidc, etc.

Core Advantages

Production Grade

Born from Alibaba’s internal product with over 2 years of production validation, supporting large-scale scenarios with hundreds of thousands of requests per second.

Completely eliminates traffic jitter caused by Nginx reload, configuration changes take effect in milliseconds and are transparent to business. Especially friendly to long-connection scenarios such as AI businesses.
Streaming Processing

Supports true complete streaming processing of request/response bodies, Wasm plugins can easily customize the handling of streaming protocols such as SSE (Server-Sent Events).

In high-bandwidth scenarios such as AI businesses, it can significantly reduce memory overhead.
Easy to Extend

Provides a rich official plugin library covering AI, traffic management, security protection and other common functions, meeting more than 90% of business scenario requirements.

Focuses on Wasm plugin extensions, ensuring memory safety through sandbox isolation, supporting multiple programming languages, allowing plugin versions to be upgraded independently, and achieving traffic-lossless hot updates of gateway logic.
Secure and Easy to Use

Based on Ingress API and Gateway API standards, provides out-of-the-box UI console, WAF protection plugin, IP/Cookie CC protection plugin ready to use.

Supports connecting to Let’s Encrypt for automatic issuance and renewal of free certificates, and can be deployed outside of K8s, started with a single Docker command, convenient for individual developers to use.

Community

Slack: to get invited go here.

Thanks

Higress would not be possible without the valuable open-source work of projects in the community. We would like to extend a special thank you to Envoy and Istio.

Higress Console: https://github.com/higress-group/higress-console
Higress Standalone: https://github.com/higress-group/higress-standalone

Contributors

Star History

↑ Back to Top ↑

Kubernetes on Producthunt daily

helm

Helm

Helm in a Handbasket

Helm Development and Stable Versions

Install

Docs

Roadmap

Community, discussion, contribution, and support

Contribution

Code of conduct

istio

Istio

Introduction

Repositories

Issue management

loki

Loki: like Prometheus, but for logs.

Getting started

Upgrading

Documentation

Getting Help

Further Reading

Contributing

Building from source

Adopters

License

airflow

Apache Airflow

Project Focus

Principles

Requirements

Getting started

Installing from PyPI

Installation

Official source code

Convenience packages

User Interface

Semantic versioning

Version Life Cycle

Support for Python and Kubernetes versions

Base OS support for reference Airflow images

Approach to dependencies of Airflow

Approach for dependencies for Airflow Core

Approach for dependencies in Airflow Providers and extras

Contributing

Voting Policy

Who uses Apache Airflow?

Who maintains Apache Airflow?

What goes into the next release?

Can I use the Apache Airflow logo in my presentation?

Links

Sponsors

kubesphere

What is KubeSphere

Demo environment

Features

Architecture

Latest release

Installation

Quick start

Installing on K8s

KubeSphere for hosted Kubernetes services

Guidance, discussion, contribution, and support

Contribution

Code of conduct

Security

Who are using KubeSphere

learn-agentic-ai

Learn Agentic AI using Dapr Agentic Cloud Ascent (DACA) Design Pattern: From Start to Scale

This Panaversity Initiative Tackles the Critical Challenge:

The Dapr Agentic Cloud Ascent (DACA) Design Pattern Addresses 10 Million AI Agents Challenge

Executive Summary: Dapr Agentic Cloud Ascent (DACA)

Target User

Why OpenAI Agents SDK should be the main framework for agentic development for most use cases?

Core DACA Agentic AI Courses:

AI-201: Fundamentals of Agentic AI and DACA AI-First Development (14 weeks)

AI-202: DACA Cloud-First Agentic AI Development (14 weeks)

AI-301 DACA Planet-Scale Distributed AI Agents (14 Weeks)

Evaluations

Distribution of `ctr` autocomplete for bash and zsh

Validating Your `cri` Setup