User Guide

Kedge Apply

Deploy directly to Kubernetes, either updating or creating the artifacts if they don’t exist.

$ kedge apply -f httpd.yaml
deployment "httpd" created
service "httpd" created

Kedge Create

Deploy directly to Kubernetes without creating the artifacts. Internally, Kedge will generate the artifacts and then create it using the kubectl command.

Deploy to Kubernetes:

$ kedge create -f httpd.yaml
deployment "httpd" created
service "httpd" created

Kedge Generate

Generate Kubernetes artifacts based upon your Kedge YAML file, see our examples or the file reference on how to create said file.

In these examples, we use the simplest of examples

Convert to Kubernetes artifacts:

$ kedge generate -f httpd.yaml
apiVersion: extensions/v1beta1
kind: Deployment
  creationTimestamp: null
    app: httpd
  name: httpd
  strategy: {}
      creationTimestamp: null
        app: httpd
      name: httpd
      - image: centos/httpd
        name: httpd
        resources: {}
status: {}
apiVersion: v1
kind: Service
  creationTimestamp: null
    app: httpd
  name: httpd
  - port: 8080
    targetPort: 80
    app: httpd
  type: NodePort
  loadBalancer: {}

Generate and deploy directly to Kubernetes:

Generation commands can also be “piped” to Kubernetes

$ kedge generate -f httpd.yaml | kubectl create -f -
deployment "httpd" created
service "httpd" created

Kedge Delete

Deletes Kubernetes artifacts

$ kedge delete -f httpd.yaml
deployment "httpd" deleted
service "httpd" deleted

Kedge Version

Outputs the current Kedge version


$ kedge version

Kedge Init

Getting started:

$ kedge init --name web --image centos/httpd --ports 80

This will create a kedge.yml file for an httpd web server with container image centos/httpd exposed on port 80.

Create a different file:

$ kedge init --out myapp.yml --name web --image centos/httpd --ports 80

This will create a different file named myapp.yml as opposed to the default kedge.yml.

Create a different controller type:

By default the controller type that is created is Kubernetes Deployments, which is meant for long running processes. But if you want to create a controller type which is Kubernetes Job, you can do that using the flag --controller.

$ kedge init --name myjob --image jobimage --controller Job

Kedge Build


Build container image with image name username/myapp:version

$ kedge build -i username/myapp:version

Here you might wanna replace the username with container image registry URL and then username.

Build & Push:

$ kedge build -i username/myapp:version -p

If you want to build image and also push it to the registry then use the flag -p.

Note: You should have access to push image to that container registry. Read more about docker login on official docs.

Dockerfile and context are different:

If you have a file structure like this, where your Dockerfile resides in a directory and your code context is different.

$ tree
├── main.go
├── parsego.go
├── scripts
│   ├── Dockerfile
│   ├──
│   └── k8s-release

To do builds in environment like above, run following command:

$ kedge build -i surajd/json-schema -c . -f scripts/Dockerfile 
INFO[0000] Building image 'surajd/json-schema' from directory 'json-schema-generator' 
INFO[0001] Image 'surajd/json-schema' from directory 'json-schema-generator' built successfully

Build in minikube/minishift:

If you are running Kubernetes in a environment like minikube or minishift run following command before running this build command:

$ eval $(minikube docker-env)

Build using source to image

You can hand off the image building work to OpenShift’s source to image utility, without having to write any Dockerfile.

To do build using OpensShift’s s2i run following command:

$ kedge build --s2i --image pyappth -b centos/python-35-centos7:3.5

Deconstructing above command, we can see that to enable using OpenShift’s s2i use the boolean flag --s2i then give the output name of the ImageStream that will be created using flag --image and finally also provide what builder image to use to do builds of the code using flag -b.

Note: Flag -b is valid only when using s2i mode. And build flag -p is not valid when in s2i mode.