airship/kubernetes-entrypoint
Code Issues Proposed changes

Clean up some spelling/grammar mistakes in the README

Browse Source
This commit is contained in:
Ian Howell 2018-12-07 09:57:54 -06:00
parent 41409ff2f4
commit 1d9d77ab12
1 changed files with 24 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
README.md
View File

@ -14,32 +14,33 @@ Kubernetes-entrypoint enables complex deployments on top of Kubernetes.
Kubernetes-entrypoint is meant to be used as a container entrypoint, which means it has to bundled in the container.
Before launching the desired application, the entrypoint verifies and waits for all specified dependencies to be met.
The Kubernetes-entrypoint queries directly the Kubernetes API and each container is self-aware of its dependencies and their states.
Therefore, no centralized orchestration layer is required to manage deployments and scenarios such as failure recovery or pod migration become easy.
Kubernetes-entrypoint queries the Kubernetes API directly, and each container is self-aware of its dependencies and their states.
Therefore, no centralized orchestration layer is required to manage deployments, and scenarios (such as failure recovery or pod migration) become easy.
## Usage
Kubernetes-entrypoint reads the dependencies out of environment variables passed into a container.
There is only one required environment variable "COMMAND" which specifies a command (arguments delimited by whitespace) which has to be executed when all dependencies are resolved:
There is only one required environment variable `COMMAND` which specifies a command (arguments delimited by whitespace) which has to be executed when all dependencies are resolved:
`COMMAND="sleep inf"`
Kubernetes-entrypoint introduces a wide variety of dependencies which can be used to better orchestrate once deployment.
## Latest features
Extending functionality of kubernetes-entrypoint by adding an ability to specify dependencies in different namespaces. The new format for writing dependencies is `namespace:name`, with the exception of pod dependencies which us json. To ensure backward compatibility if the `namespace:` is omitted, it behaves just like in previous versions so it assumes that dependecies are running at the same namespace as kubernetes-entrypoint. This feature is not implemented for container, config and socket dependency because in such cases the different namespace is irrelevant.
Extending functionality of kubernetes-entrypoint by adding an ability to specify dependencies in different namespaces. The new format for writing dependencies is `namespace:name`, with the exception of pod dependencies (which use JSON).
In order to ensure backward compatibility, if `namespace` is omitted, it is assumed that dependencies are running in the same namespace as kubernetes-entrypoint, just like in previous versions.
This feature is not implemented for Container, Config or Socket dependency because the different namespace is irrelevant for those cases.
For instance:
`
DEPENDENCY_SERVICE=mysql:mariadb,keystone-api
`
The new entrypoint will resolve mariadb in mysql namespace and keystone-api in the same namespace as entrypoint was deployed in.
The new entrypoint will resolve mariadb in the mysql namespace and keystone-api in the same namespace as kubernetes-entrypoint was deployed in.
## Supported types of dependencies
All dependencies are passed as environement variables in format of `DEPENDENCY_<NAME>` delimited by colon. For dependencies to be effective please use [readiness probes](http://kubernetes.io/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks) for all containers.
All dependencies are passed as environment variables with the format `DEPENDENCY_<NAME>`, delimited by a colon.
For dependencies to be effective please use [readiness probes](http://kubernetes.io/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks) for all containers.
### Service
Checks whether given kubernetes service has at least one endpoint.
@ -48,26 +49,26 @@ Example:
`DEPENDENCY_SERVICE=mariadb,keystone-api`
### Container
Within a pod composed of multiple containers, it waits for the containers specified by their names to start.
This dependency requires a `POD_NAME` environement variable which can be easily passed through the [downward api](http://kubernetes.io/docs/user-guide/downward-api/).
Within a pod composed of multiple containers, kubernetes-entrypoint waits for the containers specified by their names to start.
This dependency requires a `POD_NAME` environment variable which can be easily passed through the [downward api](http://kubernetes.io/docs/user-guide/downward-api/).
Example:
`DEPENDENCY_CONTAINER=nova-libvirt,virtlogd`
### Daemonset
Checks if a specified daemonset is already running on the same host, this dependency requires a `POD_NAME`
env which can be easily passed through the [downward api](http://kubernetes.io/docs/user-guide/downward-api/).
Checks if a specified daemonset is already running on the same host
This dependency requires a `POD_NAME` environment variable which can be easily passed through the [downward api](http://kubernetes.io/docs/user-guide/downward-api/).
The `POD_NAME` variable is mandatory and is used to resolve dependencies.
Example:
`DEPENDENCY_DAEMONSET=openvswitch-agent`
Simple example how to use downward API to get `POD_NAME` can be found [here](https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/user-guide/downward-api/dapi-pod.yaml).
A simple example of how to use downward API to get `POD_NAME` can be found [here](https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/user-guide/downward-api/dapi-pod.yaml).
### Job
Checks if a given job or set of jobs with matching name and/or labels succeeded at least once.
In order to use labels DEPENDENCY_JOBS_JSON must be used, but DEPENDENCY_JOBS is supported
as well for backward compatibility.
In order to use labels, `DEPENDENCY_JOBS_JSON` must be used.
DEPENDENCY_JOBS is supported as well for backward compatibility.
Examples:
`DEPENDENCY_JOBS_JSON='[{"namespace": "foo", "name": "nova-init"}, {"labels": {"initializes": "neutron"}}]'`
@ -76,34 +77,31 @@ Examples:
### Config
This dependency performs a container level templating of configuration files. It can template an ip address `{{ .IP }}` and hostname `{{ .HOSTNAME }}`.
Templated config has to be stored in an arbitrary directory `/configmaps/<name_of_file>/<name_of_file>`.
This dependency requires `INTERFACE_NAME` environment variable to know which interface to use for obtain ip address.
This dependency requires an `INTERFACE_NAME` environment variable to know which interface to use to obtain the ip address.
Example:
`DEPENDENCY_CONFIG=/etc/nova/nova.conf`
The Kubernetes-entrypoint will look for the configuration file `/configmaps/nova.conf/nova.conf`, template
`{{ .IP }} and {{ .HOSTNAME }}` tags and save the file as `/etc/nova/nova.conf`.
Kubernetes-entrypoint will look for the configuration file `/configmaps/nova.conf/nova.conf`, template the `{{ .IP }} and {{ .HOSTNAME }}` tags, and then save the file as `/etc/nova/nova.conf`.
### Socket
Checks whether a given file exists and container has rights to read it.
Checks whether a given file exists and that the container has rights to read it.
Example:
`DEPENDENCY_SOCKET=/var/run/openvswitch/ovs.socket`
### Pod
Checks if at least one pod matching the specified labels is already running, by
default anywhere in the cluster, or use `"requireSameNode": true` to require a
a pod on the same node.
As seen below the syntax uses JSON to allow for label support.
This dependency requires a `POD_NAME` env which can be easily passed through the
[downward api](http://kubernetes.io/docs/user-guide/downward-api/). The `POD_NAME` variable is mandatory and is used to resolve dependencies.
Checks if at least one pod matching the specified labels is already running, by default anywhere in the cluster, or use `"requireSameNode": true` to require a pod on the same node.
Labels are specified using JSON, as seen in the example below.
This dependency requires a `POD_NAME` env which can be easily passed through the [downward api](http://kubernetes.io/docs/user-guide/downward-api/).
The `POD_NAME` variable is mandatory and is used to resolve dependencies.
Example:
`DEPENDENCY_POD_JSON='[{"namespace": "foo", "labels": {"k1": "v1", "k2": "v2"}}, {"labels": {"k1": "v1", "k2": "v2"}, "requireSameNode": true}]'`
## Image
Build process for image is trigged after each commit.
Build process for image is triggered after each commit.
Can be found [here](https://quay.io/repository/stackanetes/kubernetes-entrypoint?tab=tags), and pulled by executing:
`docker pull quay.io/stackanetes/kubernetes-entrypoint:v0.1.0`