POST

Try using popeye, a Kubernetes Cluster Sanitizer, to help lint objects deployed to Kubernetes to detect misconfigurations, and give you some feedback on compliance with community best practices.

It seems that half the fun with software development today is creating fun new framework names, simply to give you an opportunity to create a neat product logo. Popeye makes you smile as a framework but also provides you with some valuable insight into potential flaws in your Kubernetes object configurations.

It’s essentially a linter for Kubernetes objects and we’ve been experimenting with it for our own deployments.

You can throw popeye at your cluster “raw” but you might be disappointed with the noise it produces, even with what you might consider to be “sensibly configured” objects. Nevertheless install it and run it on one of your namespaces to see what it throws up.

Armed with a Kubernetes configuration file you could run popeye on the my-namespace namespace with the following command: -

$ popeye --kubeconfig ~/k8s-config/my-config --namespace my-namespace

If your namespace has a Service object you might see output like this: -

SERVICES (5 SCANNED)                                                              E:0 W:5 I:0 OK:0 0%%
=====================================================================================================
  · data-manager-api-test/database..................................................................W
    W [POP-1109] Only one associated endpoint.
  · data-manager-api-test/dm-api....................................................................W
    W [POP-1109] Only one associated endpoint.
  · data-manager-api-test/instance-11c71cd0-3226-4989-a06c-45dfd80f5d9c.............................W
    I [POP-1102] Use of target port #8888 for service port TCP:8888-tcp:8888. Prefer named port.
    W [POP-1109] Only one associated endpoint.
  · data-manager-api-test/moldb-database............................................................W
    I [POP-1102] Use of target port #5432 for service port TCP::5432. Prefer named port.
    W [POP-1109] Only one associated endpoint.
  · data-manager-api-test/rabbitmq..................................................................W
    W [POP-1109] Only one associated endpoint.

It complains a lot.

Most of the above is warning you that there’s only one receiver for the endpoint (only one Pod when you should probably have more than one). Don’t despair - this is where popeye’s spinach files come in.

The spinach configuration file is essentially its lint configuration.

The spinach file is a YAML file that allows you to fine-control popeye’s response. For the above you could silence all the Only one associated endpoint. warnings with a spinach file like this: -

---
popeye:
  excludes:
    v1/services:
    - name: rx:data-manager-api-test
      codes:
      - 1109

If this is stored in the file my-spinach.yaml you would re-run popeye with: -

$ popeye --kubeconfig ~/k8s-config/my-config --namespace my-namespace --file my-spinach.yaml 

To see the reduced output: -

SERVICES (5 SCANNED)                                                              E:0 W:0 I:2 OK:0 0%%
=====================================================================================================
  · data-manager-api-test/instance-11c71cd0-3226-4989-a06c-45dfd80f5d9c.............................I
    I [POP-1102] Use of target port #8888 for service port TCP:8888-tcp:8888. Prefer named port.
    W [POP-1109] Only one associated endpoint.
  · data-manager-api-test/moldb-database............................................................I
    I [POP-1102] Use of target port #5432 for service port TCP::5432. Prefer named port.

And then further reduce the output by limiting it to warnings (or errors) with: -

$ popeye --kubeconfig ~/k8s-config/my-config --namespace my-namespace --file my-spinach.yaml --lint warning

To, finally, get this output: -

SERVICES (2 SCANNED)                                                            E:0 W:0 I:0 OK:2 100%%
=====================================================================================================
  · Nothing to report.

Obviously it’s bad form to silence warnings, so most of your work might be adjusting your deployment to remove them, rather than using spinach to hide them. But this was just a brief tutorial for what appears to be a really useful tool.

latest posts
by year
by category
Blog
Containers
Software design
Automation
IaC
Docking
Fragment network
Kubernetes
Web
Ansible
Python
Squonk