kubes 0.5.1 → 0.6.0

data/docs/_docs/vs/helm.md

@@ -0,0 +1,243 @@
+---
+title: Kubes vs Helm
+nav_text: Helm
+categories: vs
+---
+
+Though both Kubes and Helm can be used to deploy applications to Kubernetes, they work quite differently.  Kubernetes is more focused on deploying your application. Helm is more like a package manager.
+
+{% include vs/article.md %}
+
+## Project Structures
+
+### Helm Project Structure
+
+Here's an example of Helm project structure:
+
+    ├── Chart.yaml
+    ├── templates
+    │   ├── _helpers.tpl
+    │   ├── deployment.yaml
+    │   └── service.yaml
+    └── values.yaml
+
+The Kubernetes YAML files reside in the templates folder.  The `values.yaml` contains the default configuration values for the YAML files.
+
+{% include vs/kubes/structure.md %}
+
+## Multiple Environments: Variables vs Layering
+
+Both Helm and Kubes allow you to use the same code to create multiple environments. They take different approaches, though.
+
+### Helm Variables
+
+Helm supports creating multiple environments like dev and prod by using different variables files.  Here are example commands:
+
+    helm install chart-dev . --namespace chart-dev --create-namespace -f values/dev.yaml
+    helm install chart-prod . --namespace chart-prod --create-namespace -f values/prod.yaml
+
+To create different environments in different namespaces with helm, you use the namespace CLI options. Helm creates the namespace outside of YAML, so it's lifecycle is not managed. The `--create-namespace` option is only necessary once.  To use different variable values, you use the `-f` option. You can specify as many variables files as you wish.
+
+The commands can become verbose, as you have to remember to type the CLI options.
+
+{% include vs/kubes/layering.md %}
+
+## Templating Support
+
+Both Helm and Kubes support templating logic.
+
+### Helm Templating
+
+The templating language is a mixture of the [Go template language](https://godoc.org/text/template) and the [Sprig template library](https://masterminds.github.io/sprig/). Here's an example of Helm templating.
+
+templates/deployment.yaml
+
+```yaml
+{% raw %}apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: {{ include "mychart.fullname" . }}
+  labels:
+    {{- include "mychart.labels" . | nindent 4 }}
+spec:
+{{- if not .Values.autoscaling.enabled }}
+  replicas: {{ .Values.replicaCount }}
+{{- end }}
+  selector:
+    matchLabels:
+      {{- include "mychart.selectorLabels" . | nindent 6 }}
+  template:
+    metadata:
+    {{- with .Values.podAnnotations }}
+      annotations:
+        {{- toYaml . | nindent 8 }}
+    {{- end }}
+      labels:
+        {{- include "mychart.selectorLabels" . | nindent 8 }}
+    spec:
+      containers:
+        - name: {{ .Chart.Name }}
+          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
+          imagePullPolicy: {{ .Values.image.pullPolicy }}
+          ports:
+            - name: http
+              containerPort: 80
+              protocol: TCP{% endraw %}
+```
+
+### Kubes Templating
+
+Kubes uses ERB Ruby for templating.  Here's an example.
+
+.kubes/resources/web/deployment.yaml
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: web
+  labels:
+    role: web
+spec:
+  replicas: 1  # overridden on a env basis
+  selector:
+    matchLabels:
+      role: web
+  template:
+    metadata:
+      labels:
+        role: web
+    spec:
+      containers:
+      - name: web
+        image: <%= docker_image %>
+```
+
+The `docker_image` method is a built-in helper. It returns the Docker image built from your Dockerfile or a configured pre-built image. See: [Docker Image Docs]({% link _docs/intro/docker-image.md %}).
+
+One of the reasons why the Kubes YAML template is more straightforward is because Kubes also supports layering. So logic can be moved to different layered YAML files that get merged.
+
+## Define Custom Helpers
+
+Both Helm and Kubes support custom user-defined helpers. We'll take a look at examples from each tool.
+
+### Helm Helpers
+
+With Helm, you can define custom helpers in `templates/_helpers.tpl`. Example:
+
+templates/_helpers.tpl
+
+```go{% raw %}
+{{- define "demo.serviceAccountName" -}}
+{{- if .Values.serviceAccount.create }}
+{{- default (include "demo.fullname" .) .Values.serviceAccount.name }}
+{{- else }}
+{{- default "default" .Values.serviceAccount.name }}
+{{- end }}
+{{- end }}{% endraw %}
+```
+
+The helper methods need to be defined in the go-lang templating language, hence the need for curly brackets.
+
+### Kubes Helpers
+
+With Kubes, to define template helper methods, it's just Ruby code. Example:
+
+.kubes/helpers/my_helpers.rb
+
+```ruby
+module MyHelpers
+  def database_endpoint
+    case Kubes.env
+    when "dev"
+      "dev-db.cbuqdmc3nqvb.us-west-2.rds.amazonaws.com"
+    when "prod"
+      "prod-db.cbuqdmc3nqvb.us-west-2.rds.amazonaws.com"
+    end
+  end
+end
+```
+
+The custom helper definitions are a lot more natural.
+
+## Custom Hooks
+
+Both Helm and Kubes support hooks. This allows you to hook into the deploy lifecycle and add your own custom business logic.
+
+Helm supports a wide variety of hooks for the install, delete, upgrade, and rollback.  The hooks run at the helm-level.
+
+Kubes also supports hook as the kubes-level; this is similar to the helm-level. Kubes also provide finer-grain control hooks at the kubectl-level.
+
+Overally, Helm and Kubes hooks work quite differently. We'll take a look at **some** examples:
+
+### Helm Hook Example
+
+Helm hooks are Kubernetes Job resources with a special `helm.sh/hook` annotation. Example:
+
+templates/job.yaml
+
+```yaml
+{% raw %}apiVersion: batch/v1
+kind: Job
+metadata:
+  name: "{{ .Release.Name }}"
+  annotations:
+    "helm.sh/hook": post-install # This is what defines this resource as a hook.
+spec:
+  template:
+    metadata:
+      name: "{{ .Release.Name }}"
+    spec:
+      restartPolicy: Never
+      containers:
+      - name: post-install-job
+        image: "alpine:3.3"
+        command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"]{% endraw %}
+```
+
+So Helm hooks are just Kubernetes jobs and run on the cluster.
+
+### Kubes Hook Example
+
+Kube hooks are scripts that run on the same machine that kubes is running on. Here's an example:
+
+.kubes/config/hooks/kubectl.rb
+
+```ruby
+before("apply",
+  on: "web/deployment",
+  execute: "echo 'before apply hook test'",
+)
+```
+
+The hook will simply run the `echo` command on the same machine as what kubes is running on.  The scope is much more fine-grain.  We can target any role and resource kind. For example:
+
+    # hook can run here
+    kubectl apply -f .kubes/output/shared/namespace.yaml
+    # hook can run here
+    kubectl apply -f .kubes/output/web/service.yaml
+    # hook can run here
+    kubectl apply -f .kubes/output/web/deployment.yaml
+    # hook can run here
+
+### Hook Differences
+
+We showed examples of hooks with both Helm and Kubes. We already covered one of the differences:
+
+* Code: Helm hooks are written as Kubernetes resources. Kubes hooks are written as Ruby code that can shell out to scripts or call an inline [Ruby code]({% link _docs/config/hooks/ruby.md %}).
+* Context: Helm runs as a Kubernetes job. Kubes hooks run on the same machine as kubes itself.
+* Fine-Grain Control: With Kubes we can target the hook at each kubectl resource. Kubes also supports the coarser-grain hooks at the kubes-level. These are like helm hooks.
+
+For more info on hooks, check out the [Kubes Hooks Docs](https://kubes.guru/docs/config/hooks/).
+
+## Additional Features
+
+Helm and Kubes are quite different tools. Helm is more like a package manager. Kubes is more focused on deploying your specific application and adds additional convenient tooling.
+
+Helm can package up your applications and then helps distribute them via a helm server. It's a full-fledge package management system.
+
+Kubes supports the deployment workflow. It can build the docker image from your Dockerfile use it to deploy to Kubernetes. Kubes also has additional convenience CLI commands like [exec]({% link _reference/kubes-exec.md %}) and [logs]({% link _reference/kubes-logs.md %}) to work with Kubernetes containers.
+
+## Summary
+
+Helm and Kubes are quite different. Helm is a full-fledge package management. Kubes is a more focused on deployment. Both tools support templating logic to help keep your code DRY. Additionally, Kubes supports layering to merge YAML files together for DRYness. Kubes also helps you build your Docker images.

data/docs/_docs/vs/kustomize.md

@@ -0,0 +1,167 @@
+---
+title: Kubes vs Kustomize
+nav_text: Kustomize
+categories: vs
+---
+
+Though both Kubes and Kustomize build YAML files, they are quite different beasts. Kustomize is more like a `kubectl` feature that decorates YAML. Kubes is more like a tool. Kubes also builds YAML, but it also provides additional features.
+
+Kustomize lets you customize your Kubernetes YAML files with additional `kustomization.yaml` files. The kustomization.yaml files contain configs that tell `kubectl` how to decorate existing Kubernetes YAML files in a template-free way.
+
+Kubes lets you create Kubernetes files more directly. It handles layering and merging YAML files via a conventional structure. It also supports additional conveniences like building Docker images, CLI Customizations, Hooks, etc.
+
+{% include vs/article.md %}
+
+## Project Structures
+
+### Kustomize Project Structure
+
+Kustomize doesn't define a strict a project folder structure. You define any project structure you wish and use `kustomization.yaml` files to connect things together. Here's a possible Kustomize example project structure:
+
+    ├── base
+    │   ├── deployment.yaml
+    │   ├── kustomization.yaml
+    │   └── service.yaml
+    └── overlays
+        ├── dev
+        │   ├── deployment.yaml
+        │   ├── kustomization.yaml
+        │   └── namespace.yaml
+        └── prod
+            ├── deployment.yaml
+            ├── kustomization.yaml
+            └── namespace.yaml
+
+The provided structure allows you to use the same code to create different environments with overlays. The `overlays/dev/kustomization.yaml` file stitches the structure together.
+
+overlays/dev/kustomization.yaml:
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+  - ../../base
+patchesStrategicMerge:
+  - deployment.yaml
+namespace: demo-dev
+resources:
+- ./namespace.yaml
+```
+
+{% include vs/kubes/structure.md %}
+
+## Multiple Environments: Overlays vs Layering
+
+Both Kustomize and Kubes allow you to use the same code to create multiple environments. They take different approaches, though.
+
+### Kustomize Overlays
+
+Kustomize achieves multiple environments via `kustomization.yaml` and manually specifying and wiring how the files should merge. To create different dev and prod environments, we use overlays:
+
+    kubectl apply -k overlays/dev
+    kubectl apply -k overlays/prod
+
+{% include vs/kubes/layering.md %}
+
+## DRY Differences
+
+## DRY with Kustomize
+
+Both Kubes and Kustomize try to achieve DRY YAML code. It tries to avoid YAML duplication.
+
+Kustomize takes a purist viewpoint. You use `kustomization.yaml` to decorate original YAML.  The original files are untouched and left as-is.  Here are example overlays files.
+
+overlays/dev/kustomization.yaml:
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+  - ../../base
+patchesStrategicMerge:
+  - deployment.yaml
+namespace: demo-dev
+resources:
+- ./namespace.yaml
+```
+
+overlays/prod/kustomization.yaml:
+
+```yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+  - ../../base
+patchesStrategicMerge:
+  - deployment.yaml
+namespace: demo-prod
+resources:
+- ./namespace.yaml
+```
+
+While duplication is reduced since the original `base/deployment.yaml` is left untouched, there is duplication in the `kustomization.yaml` files.
+
+## DRY with Kubes
+
+With Kubes, DRY has handled by layering and templating support. Let's first take a look at how layering removes duplication.
+
+Let's focus on `deployment.yaml` to explain and understand layering. Here are the files that get layered.
+
+    .kubes/resources/base/all.yaml            # common YAML for all files
+    .kubes/resources/base/deployment.yaml     # common YAML for deployment kind
+    .kubes/resources/web/deployment.yaml
+    .kubes/resources/web/deployment/dev.yaml  # env-specific that overrides YAML
+
+Each file is merged together and produces a resulting YAML file:
+
+    .kubes/output/web/deployment.yaml
+
+Additionally, you can use ERB templating to keep things DRY.  Here's an example:
+
+.kubes/resources/shared/namespace.yaml
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: demo-<%= Kubes.env %>
+  labels:
+    app: demo
+```
+
+Notice the `<%= Kubes.env %>` templating logic. When is `KUBES_ENV=dev`, then `name: demo-dev`. When is `KUBES_ENV=prod`, then `name: demo-prod`.
+
+You can even define your own custom helpers for even more control. See: [Helpers Docs](https://kubes.guru/docs/helpers/custom/)
+
+## Kubes Features
+
+Kubes does a lot more than build YAML files. Here's a list of features:
+
+{% include intro/features.md %}
+
+## Kubes Kustomize Support
+
+All of that being said, Kubes also supports Kustomize.  So if you’re a Kustomize user, you can use it with Kubes. Here's an example Kustomize structure with Kubes.
+
+    .kubes/resources
+    ├── base
+    │   ├── deployment.yaml
+    │   ├── kustomization.yaml
+    │   └── service.yaml
+    └── overlays
+        ├── dev
+        │   └── kustomization.yaml
+        └── prod
+            └── kustomization.yaml
+
+In Kustomize mode, Kubes will call `kubectl apply -k`.  Here's an example:
+
+    kubes deploy overlays/dev
+
+This calls:
+
+    kubectl apply -k .kubes/output/overlays/dev
+
+## Summary
+
+Kustomize and Kubes are quite different. Kustomize is more of a feature to kubectl and takes on a purist view on changing YAML files for deployment. Kubes has similar merging concepts as Kustomize in the form of layering. Kustomize is more about control things with additional `kustomization.yaml` configurations. Whereas, Kubes takes more of a convention-over-configuration approach, so it just works without having to do extra prewiring work.  Kubes additionally helps you build your Docker images.

data/docs/_docs/vs.md

@@ -0,0 +1,10 @@
+---
+title: Kubes vs. Other Tools
+---
+
+Here are some useful comparisons to help you compare Kubes vs other tools in the ecosystem:
+
+{% assign docs = site.docs | where: "categories","vs" %}
+{% for doc in docs -%}
+* [{{ doc.nav_text }}]({{ doc.url }})
+{% endfor %}

data/docs/_includes/intro/features.md

@@ -0,0 +1,10 @@
+* Automation: [Builds the Docker image]({% link _docs/config/docker.md %}) and updates the compiled YAML files
+* Syntactic Sugar: Use an [ERB/YAML]({% link _docs/yaml.md %}) or a [DSL]({% link _docs/dsl.md %}) to write your Kubernetes YAML files. You can use a mix of DSL and YAML definitions in the `.kubes/resources` folder.
+* Layering: Use the same Kubernetes YAML to build multiple environments like dev and prod with [layering]({% link _docs/layering.md %}).
+* Generators: Kubes ships with a few generators to help you get building with Kubernetes quickly. See: [Generator Docs]({% link _docs/generators.md %}).
+* CLI Customizations: You can customize the [cli args]({% link _docs/config/args/kubectl.md %}).
+* Hooks: You can also run [hooks]({% link _docs/config/hooks.md %}) before and after [kubes]({% link _docs/config/hooks/kubes.md %}) and [kubectl]({% link _docs/config/hooks/kubectl.md %}) commands.
+* Automated Suffix Hashes: Automatically appends a suffix hash to ConfigMap and Secret resources. More details in [ConfigMap]({% link _docs/dsl/resources/config_map.md %}) and [Secret]({% link _docs/dsl/resources/secret.md %}) docs.
+* Kustomize Support: If you're a kustomization user, you can use it with Kubes. More details in [Kustomize Support Docs]({% link _docs/misc/kustomize.md %}).
+* Auto Context Switching: Map dev to a specific kubectl context and prod to another kubectl context and Kubes can switch them automatically so you won't have to remember. More details in [Auto Context Docs]({% link _docs/misc/auto-context.md %}).
+* Ordering: Kubes run kubectl apply to create resources in the [correct order]({% link _docs/intro/ordering.md %}). For deleting, it kubes will run `kubectl delete` in the correct reverse order. The order is also [customizable]({% link _docs/intro/ordering/custom.md %}).

data/docs/_includes/layering/layers.md

@@ -1,6 +1,6 @@
 Kubes Layering in it's full form allows you to keep your resource definitions DRY and create different environments with the same code.
 
-## Structure
+## Project Structure
 
 Here's an example structure, so we can understand how layering works.
 
@@ -25,9 +25,7 @@ To explain the layering, here's the general processing order that Kubes takes.
 2. Then Kubes will process your `.kubes/resources/ROLE` definitions.
 3. Lastly, Kubes processes any post-layers in the `.kubes/resources/ROLE/KIND` folders.
 
-Note, both YAML and DSL forms support layering.
-
-Layering only combines resources definitions with the same form. For example, the DSL form `base/all.rb` will not be combined with YAML form `web/deployment.yaml`.
+Note, both YAML and DSL forms support layering. They can be mixed together.
 
 ## Full Layering
 

data/docs/_includes/sidebar.html

@@ -28,6 +28,14 @@
           <li><a href="{% link _docs/learn/dsl/next-steps.md %}">Next Steps</a></li>
         </ul>
       </li>
+      <li><a href="{% link _docs/vs.md %}">Kubes vs Others</a>
+        <ul>
+        {% assign docs = site.docs | where: "categories","vs" %}
+        {% for doc in docs -%}
+          <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+        {% endfor %}
+        </ul>
+      </li>
     </ul>
     <h2><a href="{% link docs.md %}">Docs</a></h2>
     <ul id="docs">
@@ -83,6 +91,7 @@
         <ul>
           <li><a href="{% link _docs/layering/yaml.md %}">YAML</a></li>
           <li><a href="{% link _docs/layering/dsl.md %}">DSL</a></li>
+          <li><a href="{% link _docs/layering/mix.md %}">Mix</a></li>
           <li><a href="{% link _docs/layering/merge.md %}">Merge Behavior</a></li>
         </ul>
       </li>
@@ -99,6 +108,14 @@
           <li><a href="{% link _docs/dsl/multiple-resources.md %}">Multiple Resources</a>
         </ul>
       </li>
+      <li><a href="{% link _docs/variables.md %}">Variables</a>
+        <ul>
+          {% assign docs = site.docs | where: "categories","variables" %}
+          {% for doc in docs -%}
+            <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+          {% endfor %}
+        </ul>
+      </li>
       <li><a href="{% link _docs/helpers.md %}">Helpers</a>
         <ul>
           <li><a href="{% link _docs/helpers/custom.md %}">Custom</a></li>
@@ -106,7 +123,18 @@
             <ul>
               {% assign docs = site.docs | where: "categories","helpers-aws" %}
               {% for doc in docs -%}
+                {% if doc.nav_text == "Advanced" %}
+                <li><a href='{{ doc.url }}'>{{ doc.nav_text }}</a>
+                  <ul>
+                    {% assign docs = site.docs | where: "categories","advanced-helpers-aws" %}
+                    {% for doc in docs -%}
+                    <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+                    {% endfor %}
+                  </ul>
+                </li>
+                {% else %}
                 <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+                {% endif %}
               {% endfor %}
             </ul>
           </li>
@@ -114,7 +142,18 @@
             <ul>
               {% assign docs = site.docs | where: "categories","helpers-google" %}
               {% for doc in docs -%}
+                {% if doc.nav_text == "Advanced" %}
+                <li><a href='{{ doc.url }}'>{{ doc.nav_text }}</a>
+                  <ul>
+                    {% assign docs = site.docs | where: "categories","advanced-helpers-google" %}
+                    {% for doc in docs -%}
+                    <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+                    {% endfor %}
+                  </ul>
+                </li>
+                {% else %}
                 <li><a href="{{ doc.url }}">{{ doc.nav_text }}</a></li>
+                {% endif %}
               {% endfor %}
             </ul>
           </li>

data/docs/_includes/vs/article.md

@@ -0,0 +1 @@
+This article also covers more differences in detail: [Kustomize vs Helm vs Kubes: Kubernetes Deploy Tools](https://blog.boltops.com/2020/11/05/kustomize-vs-helm-vs-kubes-kubernetes-deploy-tools)

data/docs/_includes/vs/kubes/layering.md

@@ -0,0 +1,10 @@
+### Kubes Layering
+
+To deploy and create multiple environments like dev and prod with the same YAML, we use a different KUBES_ENV setting:
+
+    KUBES_ENV=dev  kubes deploy
+    KUBES_ENV=prod kubes deploy
+
+The layering is achieved thanks to the conventional project structure. You don't have to do any extra work, you just create pre-process base layer files or post-process environment specific layer files.
+
+* [Kubes Layering Docs]({% link _docs/layering.md %})

data/docs/_includes/vs/kubes/structure.md

@@ -0,0 +1,24 @@
+### Kubes Project Structure
+
+On the other hand, Kubes defines a conventional project structure. Here's a project directory example:
+
+    .kubes
+    └── resources
+        ├── base
+        │   ├── all.yaml
+        │   └── deployment.yaml
+        ├── shared
+        │   └── namespace.yaml
+        └── web
+            ├── deployment
+            │   ├── dev.yaml
+            │   └── prod.yaml
+            ├── deployment.yaml
+            └── service.yaml
+
+A Kubes project structure also supports introduces a role concept or folder. The folder structure only shows a web role for simplicity. You can always add more roles.  For example:
+
+    .kubes/resources/ROLE/deployment.yaml
+    .kubes/resources/clock/deployment.yaml
+    .kubes/resources/web/deployment.yaml
+    .kubes/resources/worker/deployment.yaml

data/docs/_reference/kubes-new-help.md

@@ -0,0 +1,15 @@
+---
+title: kubes new help
+reference: true
+---
+
+## Usage
+
+    kubes new help [COMMAND]
+
+## Description
+
+Describe subcommands or one specific subcommand
+
+
+

data/docs/_reference/kubes-new-helper.md

@@ -0,0 +1,25 @@
+---
+title: kubes new helper
+reference: true
+---
+
+## Usage
+
+    kubes new helper
+
+## Description
+
+Generates kubes helper file.
+
+## Examples
+
+    $ kubes new helper custom
+          create  .kubes/helpers/custom_helper.rb
+
+
+## Options
+
+```
+y, [--force]  # Bypass overwrite are you sure prompt for existing files
+```
+

data/docs/_reference/kubes-new-resource.md

@@ -0,0 +1,56 @@
+---
+title: kubes new resource
+reference: true
+---
+
+## Usage
+
+    kubes new resource
+
+## Description
+
+Generates Kubes Kubernetes resource definition.
+
+## Examples
+
+    $ kubes new resource ingress
+          create  .kubes/resources/web/ingress.yaml
+    $ kubes new resource service_account
+          create  .kubes/resources/shared/service_account.yaml
+    $
+
+## Supported Resources
+
+Here's a list of some of the supported resources.
+
+    backend_config
+    config_map
+    daemon_set
+    deployment
+    ingress
+    job
+    managed_certificate
+    namespace
+    network_policy
+    pod
+    role_binding
+    role
+    secret
+    service_account
+    service
+
+Refer to the source code to all the resources that the generator supports:
+https://github.com/boltops-tools/kubes/blob/master/lib/templates/new/resource/yaml
+
+
+## Options
+
+```
+a, [--app=APP]    # App name
+                  # Default: demo
+y, [--force]      # Bypass overwrite are you sure prompt for existing files
+r, [--role=ROLE]  # Role. IE: web, clock, worker, migrate, etc. Defaults to convention: web or shared when not set
+t, [--type=TYPE]  # Type: dsl or yaml
+                  # Default: yaml
+```
+

data/docs/_reference/kubes-new-variable.md

@@ -0,0 +1,20 @@
+---
+title: kubes new variable
+reference: true
+---
+
+## Usage
+
+    kubes new variable
+
+## Description
+
+Generates kubes variable file.
+
+
+## Options
+
+```
+y, [--force]  # Bypass overwrite are you sure prompt for existing files
+```
+