I've been using zabbix the last 4-5 years and its great and I love it. There have also been alot of great additions to zabbix_agent2 built in plugin LLD for docker which are phenomenal. I am also aware the kube integration has been bushed out the last few sprints. 

What i present here is a possible idea/mechanism that might make kube integration easier. The idea is similar to how zabbix has added prometheus LLD.

LLD discovery is great and phenomenal and extensible but it only for discovery items/constructs for an already discovered host.

zabbix network nmap discovery works great to let me scan the networks reachable from the server for switches and hosts.

There are many types of kube constructs aka kinds, aka resource definitions like deployments, pods, replicasets, etc. and you can have custom kube crds(custom resource definitions as well). Through the kube api we could discover all the kube orchestration constructs used by kube to orchestrate docker containers and those constructs associated metrics.

An example.

1. Allow a user to create a dummy host record for the kubernetes master/master vip.
2. Allow a user create a HTTP agent master item which does HTTP GET/POST with the kubernets api endpoint defined in the host record to get all the types of replicasets known to kube.
3. Create a Discovery rule of dependent item type, linked to the http master item from #1 to dynamically discover and prase the JSON response of Kube to discover and add zabbix applications for each discovered replicaset.
4. For each mapping of zabbix application mapped to a kube replicaset, create the applications dynamically in the form $kubeNamespace_$kubeResourceType_$kubeResourceName. for example kube-system_replicaset_nginxreplica1-1d83f.
5. WIthin the replicaset discovery rule, add item prototypes to capture the desired, current, age and ready values returned from the kube api.

 

I think this would allow for a way to have all kube constructs and kinds to be discovered by zabbix no matter what the kubernetes variations are, e.g replicaset, deployments, pods, etc. From that templated discovered trigger prototypes could be added dynamically as well. An example trigger prototype could be (#replicasetName-Ready} != (#replicasetName-Desired}.

for kube objects like pods and services that are actually bound to a host, the hosts in kube could be added to zabbix by parsing the json response of kubectl get nodes, and add hosts in the host group dynamically, very similarly to how the zabbix network nmap like discovery works today.

Macros needed for this could be added as part of the LLD macros functionality added in recent releases as needed to faciliate the kube api LLD discovery, and the same is true for the kube api endpoints, namespace, etc etc. 

This could be coupled/linked with the docker metrics gathered from the zabbix agent so that there is a 1-to-1 mapping with the docker container name and kube pod name.

Because Kubernetes objects are always changing on the cluster due to the ephemeral nature of containers and kube, i think custom discovery LLDs from http agents are a good way to link kube monitoring to zabbix. 

This same model could also be used for all other orchestration tools and application state monitoring that are, these days, only or mostly avaialble through REST APis.

Anyway, just proposal, feel free to dismiss but i know alot of people are hoping for this kube monitoring integration in zabbix and have been watching for it in release notes, jira, forums etc.