Git Product home page Git Product logo

kd's Introduction

kd - Kubernetes resources deployment tool

Build Status Docker Repository on Quay

This is a very minimalistic tool for deploying kubernetes resources.

Features

  • Go template engine support
  • Supports any kubernetes resource type
  • Polls deployment resources for completion
  • Polls statefulset resources (only with updateStrategy type set to RollingUpdates).

Running with Docker

Note that kd can be run with docker, check here for the latest image tags

docker run quay.io/ukhomeofficedigital/kd:latest --help

Installation

Please download the required binary file from the releases page

For Mac Users - Please download release kd_darwin_amd64 and run the following commands. These will ensure the binary is renamed to 'kd', it's also in your ${PATH}, and that you have permissions to run it on your system.

mv ~/Downloads/kd_darwin_amd64 /usr/local/bin/kd
chmod u+x /usr/local/bin/kd

Getting Started

The is only requirement and that is a kubectl binary in your ${PATH}. You can use the docker image or download the binary for your OS from releases page.

First, let's create a simple deployment template. Templating data comes from the environment, so in this example we'll use NGINX_IMAGE_TAG environment variable to set nginx image tag.

Create a nginx-deployment.yaml with the following content:

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 5
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:{{.NGINX_IMAGE_TAG}}
          ports:
            - containerPort: 80
          resources:
            limits:
              cpu: "0.1"
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            timeoutSeconds: 1
$ export NGINX_IMAGE_TAG=1.11-alpine
$ kd --context=mykube --namespace=testing --file nginx-deployment.yaml
[INFO] 2016/09/21 14:06:37 main.go:153: deploying deployment/nginx
[INFO] 2016/09/21 14:06:38 main.go:157: deployment "nginx" submitted
[INFO] 2016/09/21 14:06:41 main.go:194: deployment "nginx" in progress. Unavailable replicas: 5.
[INFO] 2016/09/21 14:06:56 main.go:194: deployment "nginx" in progress. Unavailable replicas: 5.
[INFO] 2016/09/21 14:07:11 main.go:190: deployment "nginx" is complete. Available replicas: 5

You can fail an ongoing deployment if there's been a new deployment by adding --fail-superseded flag.

Replace

kd will use the apply verb to create / update resources which is appropriate in most cases.

The flag --replace can be used to override this behaviour and may be useful in some very specific scenarios however the result can be a disruptive update if extra kubectl flags are applied (such as -- --force). Additionally, the last-applied-configuration is not saved when using this flag.

Cronjobs

When a cronjob object is created and only updated, any old jobs will continue and some fields are immutable, so use of the replace command and force option may be required.

# The cronjob resource does not yet exist, and so a create action is performed
$ kd --replace -f cronjob.yml -- --force
[INFO] 2018/08/07 22:54:00 main.go:724: resource does not exist, dropping --force flag for create action
[INFO] 2018/08/07 22:54:00 main.go:466: deploying cronjob/etcd-backup
[INFO] 2018/08/07 22:54:00 main.go:473: cronjob "etcd-backup" created

# The resource now exists, so a kubectl replace is performed with the extra --force arg
$ kd --replace -f cronjob.yml -- --force
[INFO] 2018/08/07 22:54:02 main.go:466: deploying cronjob/etcd-backup
[INFO] 2018/08/07 22:54:03 main.go:473: cronjob "etcd-backup" deleted
cronjob "etcd-backup" replaced

Large Objects

As an apply uses 'patch' internally, there is a limit to the size of objects that can be updated this way and you may receive an error such as: metadata.annotations: Too long: must have at most 262144 characters

Below is an example for updating a large ConfigMap:

# 859KB ConfigMap resource
$ kd --replace -f configmap.yaml
[INFO] 2018/08/07 23:02:39 main.go:466: deploying configmap/bundle
[INFO] 2018/08/07 23:02:40 main.go:473: configmap "bundle" created

$ kd --replace -f configmap.yaml
[INFO] 2018/08/07 23:02:41 main.go:466: deploying configmap/bundle
[INFO] 2018/08/07 23:02:42 main.go:473: configmap "bundle" replaced

Run command

You can run kubectl with the support of the same flags and environment variables that kd supports to simplify scripted deployments.

$ export KUBE_NAMESPACE=testland
$ kd run get po -l app=myapp -o custom-columns=:.metadata.name --no-headers

Templating

You can add the flag --debug-templates to render templates at run time. Check the examples folder for more info.

Sprig is used to add templating functions.

To preserve backwards compatibility (parameter order) the following functions still use the golang strings libraries:

  • contains
  • hasPrefix
  • hasSuffix
  • split

kd specific template functions:

Extra template functions (from helm):

split

split function is go's strings.Split(), it returns a []string. A range function can also be used to iterate over returned list.

# split.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
{{ range split .LIST "," }}
    - {{ . }}
    {{- end -}}
$ export LIST="one,two,three"
$ ./kd -f split.yaml --dryrun --debug-templates
[INFO] 2017/10/18 15:08:09 main.go:241: deploying configmap/list
[INFO] 2017/10/18 15:08:09 main.go:248: apiVersion: v1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
    - one
    - two
    - three

file

file function will locate and render a configuration file from your repo. A full path will need to be specified, you can run this in drone by using workspace: and a base directory (http://docs.drone.io/workspace/#app-drawer). Here's an example:

# file.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
{{ file .BAR | indent 4}}
$ cat <<EOF > config.yaml
- one
- two
- three
EOF
$ export BAR=${PWD}/config.yaml
$ ./kd -f file.yaml --dryrun --debug-templates
[INFO] 2017/10/18 15:08:09 main.go:241: deploying configmap/list
[INFO] 2017/10/18 15:08:09 main.go:248: apiVersion: v1
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
    - one
    - two
    - three

fileWith

fileWith function will locate and render a configuration file from your repo with additional values specified as a Sprig dict. A full path will need to be specified, you can run this in drone by using workspace: and a base directory (http://docs.drone.io/workspace/#app-drawer). Here's an example:

# file.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
{{ fileWith .BAR (dict "FIRST" "one") | indent 4}}
$ cat <<EOF > config.yaml
- {{ .FIRST }}
- two
- three
EOF
$ export BAR=${PWD}/config.yaml
$ ./kd -f file.yaml --dryrun --debug-templates
[INFO] 2017/10/18 15:08:09 main.go:241: deploying configmap/list
[INFO] 2017/10/18 15:08:09 main.go:248: apiVersion: v1
apiVersion: v1
kind: ConfigMap
metadata:
  name: list
data:
  foo:
    - one
    - two
    - three

secret

secret function generates a secret given the parameters type and length. Supported types are:

  • alphanum
  • mysql
  • yaml

NOTE a secret generated will automatically be set to create-only and will not be updated for every deploy.

# secret.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: test
data:
  # generate a mysql safe password of 20 chars
  password: {{ secret "mysql" 20 }}
$ ./kd -f ./test/secret.yaml --dryrun --debug-templates
[DEBUG] 2018/07/17 15:10:50 main.go:240: about to open file:./test/secret.yaml
[DEBUG] 2018/07/17 15:10:50 main.go:260: parsing file:./test/secret.yaml
[INFO] 2018/07/17 15:10:50 main.go:282: Template:
apiVersion: v1
kind: Secret
metadata:
  name: test
type: Opaque
data:
  username: bob
  # Create a secret suitable for mysql of 20 chars
  password: fD1wS2kzTUVVNUdJcDxGWkhedmQ=

If you are creating a kubernetes secret and need the content to be automatically base64 encoded, you can do the following:

# secret.yml
apiVersion: v1
kind: Secret
metadata:
  name: test
data:
  # read the contents of the "MY_HOSTNAME" environment variable and base64 encode it
  hostname: {{ .MY_HOSTNAME | b64enc }}
  # base64 encode the provided string
  username: {{ "my-username" | b64enc }}

k8lookup

k8lookup function allows retrieval of an Kubernetes object value using the parameters:

  • kind - a Kubernetes object kind e.g. pv or PersistentVolume
  • name - an object name e.g. sysdig-mysql-a
  • path - a object path reference e.g. .spec.capacity.storage

Example:

With manually provisioned storage (e.g. iSCSI or NFS) a PV is typically managed using a separate repository. Using lookup, we can discover the appropriate storage size for a given cluster automatically:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    name: sysdig-galera
  name: data-sysdig-galera-0
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: {{ k8lookup "pv" "sysdig-mysql-a" ".spec.capacity.storage" }}
  selector:
    matchLabels:
      name: sysdig-mysql
  storageClassName: manual

Configuration

Configuration can be provided via cli flags and arguments as well as environment variables.

Config

--config use of a .env file see github.com/joho/godotenv

Config Data

--config-data can be specified to facilitate structured yaml data in templates. It has two forms:

  1. --config-data Scope=file.yaml - data from file available at .Scope.rootkey.subkey
  2. --config-data file.yaml - data from file available at .rootkey.subkey

E.g. A deployment using source copied from a simple helm chart source:

kd --config-data Chart=./helm/simple-app/Chart.yaml \
   --config-data Values=./helm/simple-app/values.yaml \
   --allow-missing \
   --pre-render \
   --file ./helm/simple-app/templates/

NOTE the use of the flag --pre-render which allows complex charts to be parsed per file instead of per resource. This allows for blocks spanning multiple resources.

NOTE Config data is also rendered using templating. This allows upstream chart templates to be used whilst overriding values that may differ per environment (e.g. image repositories).

Kubectl flags

It supports end of flags -- parameter, any flags or arguments that are specified after -- will be passed onto kubectl.

$ kd --help
NAME:
   kd - simple kubernetes resources deployment tool

USAGE:
   kd [global options] command [command options] [arguments...]

VERSION:
   v1.10.7

AUTHOR:
   Vaidas Jablonskis <[email protected]>

COMMANDS:
     run      run [kubectl args] - runs kubectl supporting kd flags / environment options
     help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug                                debug output [$DEBUG, $PLUGIN_DEBUG]
   --debug-templates                      debug template output [$DEBUG_TEMPLATES, $PLUGIN_DEBUG_TEMPLATES]
   --dryrun                               if true, kd will exit prior to deployment [$DRY_RUN]
   --delete                               instead of applying the resources we are deleting them
   --insecure-skip-tls-verify             if true, the server's certificate will not be checked for validity [$INSECURE_SKIP_TLS_VERIFY, $PLUGIN_INSECURE_SKIP_TLS_VERIFY]
   --kube-config-data value               Kubernetes config file data [$KUBE_CONFIG_DATA, $PLUGIN_KUBE_CONFIG_DATA]
   --kube-server URL, -s URL              kubernetes api server URL [$KUBE_SERVER, $PLUGIN_KUBE_SERVER]
   --kube-token TOKEN, -t TOKEN           kubernetes auth TOKEN [$KUBE_TOKEN, $PLUGIN_KUBE_TOKEN]
   --kube-username USERNAME, -u USERNAME  kubernetes auth USERNAME [$KUBE_USERNAME, $PLUGIN_KUBE_USERNAME]
   --kube-password PASSWORD, -p PASSWORD  kubernetes auth PASSWORD [$KUBE_PASSWORD, $PLUGIN_KUBE_PASSWORD]
   --config value                         Env file location [$CONFIG_FILE, $PLUGIN_CONFIG_FILE]
   --config-data value                    Config data e.g. --config-data=Chart=./Chart.yaml [$KD_CONFIG_DATA, $PLUGIN_KD_CONFIG_DATA]
   --create-only                          only create resources (do not update, skip if exists). [$CREATE_ONLY, $PLUGIN_CREATE_ONLY]
   --create-only-resource value           only create specified resources e.g. 'kind/name' (do not update, skip if exists). [$CREATE_ONLY_RESOURCES, $PLUGIN_CREATE_ONLY_RESOURCES]
   --replace                              use replace instead of apply for updating objects [$KUBE_REPLACE, $PLUGIN_KUBE_REPLACE]
   --context CONTEXT, -c CONTEXT          kube config CONTEXT [$KUBE_CONTEXT, $PLUGIN_CONTEXT]
   --namespace NAMESPACE, -n NAMESPACE    kubernetes NAMESPACE [$KUBE_NAMESPACE, $PLUGIN_KUBE_NAMESPACE]
   --fail-superseded                      fail deployment if it has been superseded by another deployment. WARNING: there are some bugs in kubernetes. [$FAIL_SUPERSEDED, $PLUGIN_FAIL_SUPERSEDED]
   --certificate-authority PATH           the path (or URL) to a file containing the CA for kubernetes API PATH [$KUBE_CERTIFICATE_AUTHORITY, $PLUGIN_KUBE_CERTIFICATE_AUTHORITY]
   --certificate-authority-data PATH      the certificate authority data for the kubernetes API PATH [$KUBE_CERTIFICATE_AUTHORITY_DATA, $PLUGIN_KUBE_CERTIFICATE_AUTHORITY_DATA]
   --certificate-authority-file value     the path to save certificate authority data to when data or a URL is specified (default: "/tmp/kube-ca.pem") [$KUBE_CERTIFICATE_AUTHORITY_FILE, $PLUGIN_KUBE_CERTIFICATE_AUTHORITY_FILE]
   --file PATH, -f PATH                   the path to a file or directory containing kubernetes resources PATH [$FILES, $PLUGIN_FILES]
   --timeout TIMEOUT, -T TIMEOUT          the amount of time to wait for a successful deployment TIMEOUT (default: 3m0s) [$TIMEOUT, $PLUGIN_TIMEOUT]
   --check-interval INTERVAL              deployment status check interval INTERVAL (default: 1s) [$CHECK_INTERVAL, $PLUGIN_CHECK_INTERVAL]
   --allow-missing                        if true, missing variables will be replaced with <no value> instead of generating an error [$ALLOW_MISSING]
   --kubectl-binary value                 the path to the kubectl binary (default: "kubectl") [$KUBE_BINARY, $KUBECTL_BINARY]
   --help, -h                             show help
   --version, -v                          print the version

Build

To build kd just run make.

You can also build kd in a docker container:

docker run --rm -v $PWD:/go/src/github.com/UKHomeOffice/kd -w /go/src/github.com/UKHomeOffice/kd -ti golang:1.10 make

Release process

Push / Merge to master will produce a docker image with a tag latest.

To create a new release, just create a new tag off master.

Contributing

We welcome pull requests. Please raise an issue to discuss your changes before submitting a patch.

Author

Vaidas Jablonskis vaijab

kd's People

Contributors

asmith030 avatar awkwardben avatar daniel-ac-martin avatar danielepolencic avatar dewaldv avatar easternbloc avatar gambol99 avatar gjkrupa avatar jaykeshur avatar joechapman avatar joseph-irving avatar kashifsaadat avatar kmahmood2021 avatar lewismarshall avatar marcinc avatar oyelekci avatar tasharnvb avatar timgent avatar tom-haynes avatar vaijab avatar xiii avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kd's Issues

EOF if document contains --- in the middle of a condition block since 1.8.0

For example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-map
data:
    my.value: 1
{{if eq .KUBE_NAMESPACE "my-prod"}}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-map-2
data:
    my.value: 2
{{end}}

We see the following error:

[ERROR] 2018/09/18 17:56:52 render.go:33: template: template:8: unexpected EOF

The last working version with these templates I can find is v0.13.0

Watch Methods

The watch methods for job, statefulset etc look near enough identical .. we should wrap them into one method

Potentially skip kd run operations when DRY_RUN is specified

When running kd as part of CI it is useful to use the DRY_RUN environment variable to just ensure all files exists and templates etc. are parsed. These scripts will always fail if DRY_RUN doesn't apply to kd run operations without adding complexity to these scripts.

E2E tests

We have no visibility of if and when kubectl updates can fail (#69) or if the follow functions work (manual testing required for e.g. #68).

We could add an E2E test using our testing cluster using each of the deployment types we watch. This may meen using drone instead of travis - unless there's a public k8 test option out there...

BUG with kubectl v1.10.0

It appears the latest version of kubectl is not compatible with v1.9.6

Marks-MacBook-Pro:prest molliver$ kd --config /Users/molliver/git/borders/platform/kube-secrets/dev.env -f ./network-policy.yaml
[INFO] 2018/03/29 10:53:55 main.go:278: deploying networkpolicy/prest
[ERROR] 2018/03/29 10:53:56 main.go:122: Error from server (NotAcceptable): unknown
Marks-MacBook-Pro:prest molliver$ which kubectl
/usr/local/bin/kubectl
Marks-MacBook-Pro:prest molliver$ sum which kubectl
5542 52618 /usr/local/bin/kubectl
Marks-MacBook-Pro:prest molliver$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6+a08f5eeb62", GitCommit:"c84beff", GitTreeState:"clean", BuildDate:"2018-03-15T19:58:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Yet when I switch just kubectl back to the earlier 1.9.6 version kd works fine.

Regards

Mark

Environment variable for KUBE_CERTIFICATE_AUTHORITY not working

Can't reproduce @KashifSaadat :
Setup kubectl context:

~/go/src/github.com/UKHomeOffice/kd master[]> kubectl config use-context minikubeinsecure
Switched to context "minikubeinsecure".
~/go/src/github.com/UKHomeOffice/kd master[]> kubectl get po
Unable to connect to the server: x509: certificate signed by unknown authority

Use environment var KUBE_CERTIFICATE_AUTHORITY, note kubectl flag in debug:

~/go/src/github.com/UKHomeOffice/kd master[]> DEBUG=true KUBE_CERTIFICATE_AUTHORITY=/home/lewis/.minikube/ca.crt  ./bin/kd -f ./test/deployment.yaml
[DEBUG] 2018/07/20 12:24:39 main.go:252: about to open file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:24:39 main.go:272: parsing file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:24:39 main.go:384: about to deploy resource Deployment/nginx-deployment (from file:"./test/deployment.yaml")
[DEBUG] 2018/07/20 12:24:39 main.go:392: kubectl arguments: "kubectl --certificate-authority=/home/lewis/.minikube/ca.crt apply -f -"
[INFO] 2018/07/20 12:24:39 main.go:408: deploying deployment/nginx-deployment
[INFO] 2018/07/20 12:24:39 main.go:415: deployment "nginx-deployment" configured
[DEBUG] 2018/07/20 12:24:39 main.go:443: sleeping 3 seconds before checking Deployment status for the first time
[DEBUG] 2018/07/20 12:24:44 main.go:493: fetching Deployment "nginx-deployment" status: {ObservedGeneration:1 Replicas:3 UpdatedReplicas:3 AvailableReplicas:3 UnavailableReplicas:0 ReadyReplicas:3 CurrentRevision: UpdateRevision: CurrentNumberScheduled:0 DesiredNumberScheduled:0 NumberAvailable:0 NumberMisscheduled:0 NumberReady:0 NumberUnavailable:0 UpdatedNumberScheduled:0 Succeeded:0}
[INFO] 2018/07/20 12:24:44 main.go:532: Deployment "nginx-deployment" is complete. Available objects: 3

Now test that insecure flag works too:

~/go/src/github.com/UKHomeOffice/kd master[]> DEBUG=true INSECURE_SKIP_TLS_VERIFY=true  ./bin/kd -f ./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:13 main.go:252: about to open file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:13 main.go:272: parsing file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:13 main.go:384: about to deploy resource Deployment/nginx-deployment (from file:"./test/deployment.yaml")
[DEBUG] 2018/07/20 12:28:13 main.go:392: kubectl arguments: "kubectl --insecure-skip-tls-verify apply -f -"
[INFO] 2018/07/20 12:28:13 main.go:408: deploying deployment/nginx-deployment
[INFO] 2018/07/20 12:28:13 main.go:415: deployment "nginx-deployment" configured
[DEBUG] 2018/07/20 12:28:13 main.go:443: sleeping 3 seconds before checking Deployment status for the first time
[DEBUG] 2018/07/20 12:28:17 main.go:493: fetching Deployment "nginx-deployment" status: {ObservedGeneration:1 Replicas:3 UpdatedReplicas:3 AvailableReplicas:3 UnavailableReplicas:0 ReadyReplicas:3 CurrentRevision: UpdateRevision: CurrentNumberScheduled:0 DesiredNumberScheduled:0 NumberAvailable:0 NumberMisscheduled:0 NumberReady:0 NumberUnavailable:0 UpdatedNumberScheduled:0 Succeeded:0}
[INFO] 2018/07/20 12:28:17 main.go:532: Deployment "nginx-deployment" is complete. Available objects: 3

And finally that no CA flags fails appropriately:

~/go/src/github.com/UKHomeOffice/kd master[]> DEBUG=true ./bin/kd -f ./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:23 main.go:252: about to open file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:23 main.go:272: parsing file:./test/deployment.yaml
[DEBUG] 2018/07/20 12:28:23 main.go:384: about to deploy resource Deployment/nginx-deployment (from file:"./test/deployment.yaml")
[DEBUG] 2018/07/20 12:28:23 main.go:392: kubectl arguments: "kubectl apply -f -"
[INFO] 2018/07/20 12:28:23 main.go:408: deploying deployment/nginx-deployment
[ERROR] 2018/07/20 12:28:24 main.go:173: W0720 12:28:24.080825   22770 factory_object_mapping.go:423] Failed to download OpenAPI (Get https://192.168.99.100:8443/swagger-2.0.0.pb-v1: x509: certificate signed by unknown authority), falling back to swagger
error: error when retrieving current configuration of:
&{0xc42030b140 0xc42031f260 default nginx-deployment STDIN 0xc42000c5c8 0xc42000c5c8  false}
from server for: "STDIN": Get https://192.168.99.100:8443/apis/apps/v1/namespaces/default/deployments/nginx-deployment: x509: certificate signed by unknown authority

Support Environment Config Files

It would be good if we can load environment specific config files up rather than having to export all variables to the environment.

Ideally we should be able to use either Viper to read many config sources but that might be overkill or probably better in this instance gotenv which reads .env files.

This will better allow us to keep track of the options for each environment.

Thanks

Mark

Add secret templating generation

To enable kubernetes as a source of truth for secrets and to reduce manual error, we should remove the manual step required to manage them.

This is especially useful for test and staging environments.

Add a template function e.g. {{ password "alphanumeric"|"complex"|"mysql" [length] }}.

By default, a secret generated using this feature should probably only ever be created and not updated.

Wildcard in files causes timeout option to fail

If I run the following command it works fine:

kd -f deploy/specific-deployment.yml --timeout 10m0s

However the same command, but using a wildcard to match multiple files fails with the following error:

kd -f deploy/*-deployment.yml --timeout 10m0s
[ERROR] 2020/08/20 14:15:20 main.go:248: Error: unknown flag: --timeout

This is using 1.16.0

Ensure resources deployment order

Currently kd doesn't seem to respect the order of supplied kubernetes resources. Ensuring the order of execution could help in cases where some of resources depend on other.

Add --create-only flag for sensitive resources

When creating Secrets and PV's it is desirable to use kubernetes as a source of truth and not to replace these objects if they change.

Add a --create-only flag to identify these deployments to allow for this.

bad error message when can't download CA

Get a generic problem with no context when a CA can't be downloaded:

[ERROR] 2018/07/30 09:30:34 main.go:187: problem checking if resource Secret/ingress-raw-pw exists
[failed] problem creating / checking ingress-raw-pw

When run with debug:

[DEBUG] 2018/07/30 09:30:54 main.go:279: about to open file:./kube/ingress-raw-pw.yml
[DEBUG] 2018/07/30 09:30:54 main.go:299: parsing file:./kube/ingress-raw-pw.yml
[DEBUG] 2018/07/30 09:30:54 main.go:688: ca file specified as /tmp/kd017941543/kube-ca.pem, to download from https://[REDACTED]
[ERROR] 2018/07/30 09:30:54 main.go:187: problem checking if resource Secret/ingress-raw-pw exists
+ failed 'problem creating / checking ingress-raw-pw'
+ log '[failed] problem creating / checking ingress-raw-pw'

Add --wait-for flag to allow for staged deployments

In CI and Testing environments deployments include "setup logic" that needs to wait until some workloads are ready before trying to connect and complete deployment steps.

  • Adding a --wait-for flag will ensure a workload is ready before continuing with deployments specified (or exiting when ready).
    Possible parameter value syntax: pod/name|label=value:[first|all] to enable pod based on name or selector and first pod
  • Ensure this timeout also supports the existing kd timeout switch.

Don't block waiting for individual deployments

Currently kd will block while it waits for an individual deployment to rollout before deploying any other resources. A more sophisticated approach would be to instead deploy all resources and track the rollout of the 'watchable' ones at the end.

This would allow for faster overall deployments.

Support KUBE_CONFIG_DATA

Support a complete /tmp/.kube/config file where specified.

This would help where we have this specified already in CI and provide a useful config option?

Add debugging option

To help with debugging , when running kd in debugging mode, cache locally in a .kd/ directory the yaml or json response received from the kubelet.
@vaijab suggested that another option is to output the yaml/json from kubectl to stdout , that works too for debugging.

Fire and forget mode

I think kd should have a 'fire and forget' mode. i.e. It should be possible to create a deployment and move on without waiting for its rollout to complete. There a two reasons for this:

  1. Inter-dependent deployments - Let's say micro-service B requires micro-service A to have started before it can start. But micro-service A is not ready until micro-service B has started.

  2. Deployment speed - In many cases two services will not rely on each other and so it makes no sense for us to deploy in sequence. Rather, we should deploy them in parallel. That way they can each be rolling out and the same time and reduce the overall time taken to deploy the service.

Keep kd version tag in-line with the kubectl version

kubectl only officially supports +/-1 version of the Kubernetes Cluster you are interacting with. For kd users, they would currently need to dig through the releases and code to find out which version would be compatible with the cluster they are interacting with.

It may be better to tie the release version of kd with the version of kubectl that is bundled, for example: v1.10.3_p1

Add templating to lookup values from other resources

Deployment values can be tied to values from other kubernetes resources which are themselves managed in other repositories.

Add a function to perform a resource value lookup. In the following example, the storage size required for a PVC could be obtained from the manually deployed PV e.g.:

{{ k8value pv mypvname ".spec.capacity.storage" }}

Show rendered template when invalid yaml

As --dry-run -o yaml will only output errors if the file is valid yaml it would still be usefull to get the template result to determin where in a file an error is.

bash-4.3# kd -f kube/config-bx.yml -- --dry-run -o yaml
[ERROR] 2018/04/17 11:03:32 main.go:123: yaml: line 28: could not find expected ':'

Would like to add a flag to show rendered templates e.g. --debug-templates.

Allow update of objects that are too large for kubectl apply command

Optionally support the verb replace over apply for large objects or objects that need replacing like cronjobs (you want old jobs to be deleted).

This is also useful for large configmaps over ~800K.

Document the flag and also the optional extra args that are useful in some cases:
-- --save-config=false and or -- --force.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.