kubepy
Python wrapper on kubectl that makes deploying easy.
Installation
Requires python 3.5 and configured kubectl. To install run:
pip3 install kubepy
Usage
You can use this package to install all yml definitions from given directory.
Just run kubepy-apply-all from a directory where all of you Kubernetes definition yml files are.
Supported Kubernetes resources:
- CronJob
- Deployment
- StatefulSet
- Job
- Pod (used to run a one-off command)
- Service
- Ingress
- Secret
- StorageClass
- PersistentVolume
- PersistentVolumeClaim
- PodDisruptionBudget
Options:
--directory <path>- uses path instead of local directory. Can be used multiple times to add new and partially override existing definitions.--build-tag <tag>- sets tag to all images without specified tag in your definition files--label <key>=<value>- adds label to definition. Can be used multiple times.--label-pod <key>=<value>- adds label to each pod definition. Can be used multiple times.--annotate <key>=<value>- adds annotation to definition. Can be used multiple times.--annotate-pod <key>=<value>- adds annotation to each pod definition. Can be used multiple times.--replace- if present, replaces deployments instead of updating them. Default: false.--host-volume <name>=<path>Adds host volume to each pod definition. Can be used multiple times.--env <VAR>=valueSets environment variable on every container.--max-job-retries <n>While waiting for job to finish if it fails n times than delete job and fail. Job sometimes can still be executed more than n times.--namespace <name>- applies definitions into this namespace, unless the definition setsmetadata.namespaceitself.
There is also kubepy-apply-one command which is called as kubepy-apply-one name1 [name2 ...]
It applies only files selected files. Names should be without ".yml".
It accepts all options from kubepy-apply-all. Additionally you can pass option:
--show-definition- shows definition instead of applying them.
Applying jobs.
Applying usualy means that underlying kubectl apply or kubectl replace is called. However applying job is treated
differently.
To ensure that job finished and succeeded kubectl waits for job to finish and fails if job failed.
Applying pods.
Usually you don't need to apply pods manually, but if you want to run some kind of check and you need to know if it
succeeded without retries then you can use pod with restartPolicy: Never. Only pods with this policy are currently
supported. They are treated as jobs, so applying waits for them to finish and fails if they fail.
Metadata
Release files for kubepy 1.21.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| kubepy-1.21.0.tar.gz | 13.5 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| kubepy-1.21.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 26.9 kB
Release files / kubepy-1.21.0.tar.gz
| Download URL | kubepy-1.21.0.tar.gz |
|---|---|
| Size | 13.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
43b4c91cf56272c950ec81e0bb149d513fe30077518ae3cf50f70bf7dffda3fd
|
|
BLAKE2b-256 checksum How to use checksums |
8642ad56252cc4fdbc396f5d7290864e3a6ef8445ff9d6a6af42e6f9c27192ef
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.13
|
Release files / kubepy-1.21.0-py3-none-any.whl
| Download URL | kubepy-1.21.0-py3-none-any.whl |
|---|---|
| Size | 13.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0d096ce4799b8f9d7f097b603c863c75b34f5343673cd4fc0a4648a8e5bfe8fb
|
|
BLAKE2b-256 checksum How to use checksums |
3f593aa53ca4cc06b289e6e80dc2e14a1beb54ff37e153185cffd0f3eced5e6a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.12.13
|
Security for kubepy 1.21.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.