Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Eval

Alpha Feature: turn it on with --features=eval (see Feature gates).

Eval is very similar to show but it differs in a fundamental way, it does not traverse the code in search of kubernetes manifests, it instead behaves more like jsonnet command and does just evaluate the jsonnet code to output

This is useful in order to troubleshoot some jsonnet code that , because of the use of kubecfg native extension, cannot be rendered using standard jsonnet

Jsonnet Code

local kubecfg = import 'kubecfg.libsonnet';

{
  local outer = self,

  container:: {
    name: 'busybox',
    image: 'busybox:latest',
  },

  deployment: {
    local this = self,

    apiVersion: 'extensions/v1beta1',
    kind: 'Deployment',
    metadata: {
      name: 'busybox',
      labels: { name: 'busybox' },
    },
    spec: {
      replicas: 3,
      template: {
        metadata: { labels: this.metadata.labels },
        spec: {
          containers: [outer.container],
        },
      },
    },
  },
}

Basic Rendering

render jsonnet to stdout in YAML format

kubecfg --features=eval eval source.jsonnet

➜ kubecfg --features=eval eval code.jsonnet
deployment:
  apiVersion: extensions/v1beta1
  kind: Deployment
  metadata:
    labels:
      name: busybox
    name: busybox
  spec:
    replicas: 3
    template:
      metadata:
        labels:
          name: busybox
      spec:
        containers:
        - image: busybox:latest
          name: busybox

render to stdout in JSON format

kubecfg --features=eval eval -o json source.jsonnet

{
   "deployment": {
      "apiVersion": "extensions/v1beta1",
      "kind": "Deployment",
      "metadata": {
         "labels": {
            "name": "busybox"
         },
         "name": "busybox"
      },
      "spec": {
         "replicas": 3,
         "template": {
            "metadata": {
               "labels": {
                  "name": "busybox"
               }
            },
            "spec": {
               "containers": [
                  {
                     "image": "busybox:latest",
                     "name": "busybox"
                  }
               ]
            }
         }
      }
   }
}

Evaluating an expression

-e evaluates an expression instead of the whole file. In the expression, $ is the value of the file:

$ kubecfg --features=eval eval code.jsonnet -e '$.deployment.spec.replicas'
3

Using kubecfg without importing it

In the expression, kubecfg is already defined, so you can call the functions of kubecfg.libsonnet without importing it:

$ kubecfg --features=eval eval code.jsonnet -e 'kubecfg.fold(kubecfg.layouts.gvkName, $, {})'
extensions/v1beta1.Deployment:
  busybox:
    apiVersion: extensions/v1beta1
    ...

It’s always the copy of kubecfg.libsonnet built into kubecfg. A file with that name on the search path (-J) or next to the evaluated file doesn’t change it. A name you define yourself wins, such as a local kubecfg or a top-level argument named kubecfg. So to use another copy, import it: -e 'local kubecfg = import "kubecfg.libsonnet"; ...' finds it the usual way.

The same goes for the code of --exec, --overlay-code, --ext-code and --tla-code, and for the expressions in YAKL files. It doesn’t for Jsonnet files: they still need the import, so editors, linters and other Jsonnet tools can read them. RFC06 explains why.

Seeing the Jsonnet of a YAKL file

kubecfg --features=eval,yakl eval -o jsonnet app.yakl prints the Jsonnet that a YAKL file compiles to, without evaluating it. See Seeing the generated Jsonnet.