ktest

ktest

Simple test app for Knative deployments

To use the ktest application you will have to deploy it to an existing Knative cluster. See Knative Installation if you don't have one.

Demo

https://ktest.demo.knative.tech/

Deploy

kubectl apply -f https://raw.githubusercontent.com/mchmarny/ktest/master/deployments/service.yaml

After deployment, the ktest application will expose the following endpoints:

• / Landing page with links to this endpoints
• /kn Knative-specific data as defined in the Runtime Contract
• /req Request context with environment variables and headers
• /res Serving node info (Hostname, OS, Boot-time) and Pod available Memory/CPU resources
• /log Content of specific log or log list in dir (e.g. /log?logpath=/var/log/app.log)
• /_health Responds with 'OK' (ala health check)

Endpoint How-to

The JSON outputting endpoints (/kn, /req, /res) include request metadata object. This provides context for each response and is useful when persisting returned data for evaluation/texting.

{
    "meta": {
        "id": "215bb44e-0513-44a5-a640-fc1546daf294",
        "ts": "2019-01-04T20:09:12.52097224Z",
        "uri": "/req",
        "host": "ktest.demo.knative.tech",
        "method": "GET"
    },
    ...

req - HTTP Request

The /req endpoint provides an easy way to eval expected environment variables or headers for your requests. For example to get a release version of the ktest1 app you would execute:

curl -s https://ktest.demo.knative.tech/req |  jq '.envs.RELEASE'

Or to get your user-agent as seen by the Knative service

curl -s https://ktest.demo.knative.tech/req |  jq '.head."user-agent"'

/node (Serving Node)

The /node endpoint provides information about the node which is serving your request. For example to see the boot time of that node and its hostname

curl -s https://ktest.demo.knative.tech/res |  jq '.node.bootTs,.meta.host'

/kn (Knative)

The /kn endpoint is what you would use to evaluate Knative-specific data. In addition to the Knative environment variables (PORT and ones prefixed by K_ like K_CONFIGURATION, K_REVISION, and K_SERVICE), the /kn endpoint also exposes information about the recommended file system mounts (e.g. /tmp, /var/log, or /dev/log).

To test for example if the /etc/hosts has the required R/W permissions you can run this query. It searches for comment in the returned document where access group name == "DNS" and and the item within that group has the path == /etc/hosts

curl -s https://ktest.demo.knative.tech/kn \
  | jq -r --arg group "DNS" \
    '.access[] | if .group == $group then . else empty end' \
    | jq -r --arg path "/etc/hosts" \
      '.list[] | if .path == $path then .comment else empty end'

/log

The /log endpoint returns the log file specified by the logpath parameter in query string. ((e.g. /log?logpath=/var/log/ktest.log)). If the logpath parameter is a directly the /log will return a list of content in that directory.

Note, ktest by default writes logs to stdout unless the LOG_TO_FILE environment variable is set (anything other than "" will do). If that variable is set, ktest will output its own logs to /var/log/ktest.log

Note, currently the /log endpoint will not return any logs larger than 1MB.

To search log you can pipe the /log output through greb. For example to find out the port on which the server started

curl -s https://ktest.demo.knative.tech/log?logpath=/var/log/ktest.log \
  | grep 'Server starting on port'