Use kubeconfig as one of the optional parameters for creating KubernetesHook
- Dominant language
- Python
- Stars
- 46.9k
- Forks
- 17.8k
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 484
Description
### Description
When we use `KubernetesPodOperator`, we need to create `KubernetesHook` in order to connect to Kubernetes services. There are currently 3 supported methods for creating `KubernetesHook`:
1、environment variable method,
2、kubeconfig_path method,
3、db connection variable method.

However, these methods are all from the perspective of the airflow system owner. The airflow owner can change the variables of the airflow_worker, create and modify files in the airflow_worker, and operate the airflow_db. However, in many cases, the users of airflow are not The owner of airflow, The user does not have the authority to make changes to the airflow_worker, nor does it have read and write permissions to the db, nor should it see the data stored in the db by other users.
Therefore, it is best for users to manage their own data rather than hosting it on the airflow system, in this case, it is a relatively reasonable choice to add an optional parameter to receive the kubeconfig text.
### Use case/motivation
add an optional parameter to receive the kubeconfig text

If this proposal is accepted, I will happily submit a PR to support this feature
### Related issues
_No response_
### Are you willing to submit a PR?
- [X] Yes I am willing to submit a PR!
### Code of Conduct
- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
Contributor guide
Research direction
Start by locating KubernetesPodOperator and KubernetesHook, then inspect the existing environment-variable, kubeconfig_path, and database-connection creation paths. Confirm how an optional kubeconfig text value should interact with those methods and define tests showing that users can provide it without changing worker files or database variables.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, python
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100