https://github.com/chickenzord/kube-rule
Kubernetes pods admission webhook based on rules CRD
https://github.com/chickenzord/kube-rule
kubernetes kubernetes-controller kubernetes-crd kubernetes-namespace kubernetes-webhook
Last synced: 2 months ago
JSON representation
Kubernetes pods admission webhook based on rules CRD
- Host: GitHub
- URL: https://github.com/chickenzord/kube-rule
- Owner: chickenzord
- License: mit
- Created: 2019-01-10T11:50:35.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2019-08-14T10:15:54.000Z (about 6 years ago)
- Last Synced: 2024-06-20T12:38:32.475Z (over 1 year ago)
- Topics: kubernetes, kubernetes-controller, kubernetes-crd, kubernetes-namespace, kubernetes-webhook
- Language: Go
- Homepage:
- Size: 55.7 KB
- Stars: 11
- Watchers: 2
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# kube-rule
[](https://travis-ci.org/chickenzord/kube-rule)
[](https://goreportcard.com/report/github.com/chickenzord/kube-rule)
[](https://codecov.io/gh/chickenzord/kube-rule)
[](https://hub.docker.com/r/chickenzord/kube-rule/)
[](https://hub.docker.com/r/chickenzord/kube-rule/)
[](https://app.fossa.io/projects/git%2Bgithub.com%2Fchickenzord%2Fkube-rule?ref=badge_shield)
Kubernetes pods admission webhook based on rules CRD. Rewrite of [kube-annotate](https://github.com/chickenzord/kube-annotate) with more generalized uses.
## TL;DR
You will be able to create these Custom Resource Definitions (CRDs) ...
```yaml
apiVersion: kuberule.chickenzord.com/v1alpha1
kind: PodRule
metadata:
name: staging-rule
namespace: awesome-staging
spec:
selector:
matchLabel:
tier: app
mutations:
annotations:
example.com/log-enabled: 'true'
example.com/log-provider: 'a-cheap-logging-stack'
nodeSelector:
kubernetes.io/role: app
imagePullSecrets:
- name: dockerhub-creds
---
apiVersion: kuberule.chickenzord.com/v1alpha1
kind: PodRule
metadata:
name: production-rule
namespace: awesome-production
spec:
selector:
matchLabel:
tier: app
mutations:
annotations:
example.com/log-enabled: 'true'
example.com/log-provider: 'awesome-and-expensive-logging-stack'
nodeSelector:
kubernetes.io/role: app
example.com/env: production
tolerations:
- key: dedicated-env
operator: Equals
value: production
imagePullSecrets:
- name: dockerhub-creds
```
Don't get it? Basically it allows you to automatically add some predefined specs to selected Pods in certain namespaces. Supports for other resource objects and specs might be added in the future.
## Motivations
> **Why don't you just add those specs to the controller resources directly?** (e.g. `Deployment.spec.template`)
Separation of responsibilities. In a multi-tenants cluster (i.e. shared with multiple teams/organizations) you might not want to complicate already-settled development/deployment flows. With **kube-rule**, Developers can define how their apps run (e.g. image, command, probes), while cluster operators decide where the apps run (e.g. nodeSelector, affinity, tolerations, etc).
Using CRD simplifies a lot of things. Anyone can leverage any existing tools that understand how to interact with Kubernetes resources (e.g kubectl, kustomize, ksonnet, etc).
## How to install
### Quick installation
```sh
make quick-install
```
Above command will create CRDs, a namespace `kuberule` and install the controller into it. You might need cluster admin role.
### Recommended installation
We recommend installing kube-rule using Helm Chart (TODO)
## Development
This tool code was bootstrapped using [kubebuilder](http://kubebuilder.netlify.com/) version `1.0.7`.
## Goals and Non-Goals
**What mutation spec should kube-rule supports?**
Basically kube-rule aims to support Pod specs that can be implicitly **decided by cluster admins** depending on where the app runs (i.e. environment-dependent).
Example of specs mutation that **will not get supported** by kube-rule:
- `containers.image`: Images deployed should be decided by CI/CD in app layer tooling.
- `containers.commands`/`containers.args`: Overriding them requires knowledge of the container image used.
- `volumes`/`volumeMounts`: Volumes used are closely tied to app logic.
- etc...
Feel free to request more specs by describing your valid use-case in Pull Requests.
## TODO
- Helm Chart (high priority)
- Namespace selector in the controller
- Support more specs:
- ~~tolerations~~
- ~~podAffinity~~
- ~~nodeAffinity~~
- containers.resources
- etc
- Support more resources: deployments, statefulsets, daemonsets, etc
- ClusterPodRule CRD (cluster-wide version of PodRule)
## License
[](https://app.fossa.io/projects/git%2Bgithub.com%2Fchickenzord%2Fkube-rule?ref=badge_large)