Also, the documentation at https://git.zabbix.com/projects/ZT/r...Frelease%2F6.0 suggests changing the chart values according to the environment but does not explain what values should be changed and what environment is to be considered.

Surely the default variables are wrong because

$ kubectl logs  zabbix-proxy-986db979c-7bqxn
171:20220411:182131.966 misconfiguration error: the proxy is running in the active mode but server at "127.0.0.1" sends requests to it as to proxy in passive mode
   170:20220411:182131.966 received configuration data from server at "127.0.0.1", datalen 189
   170:20220411:182131.967 failed to update local proxy configuration copy: cannot open JSON object or array ""failed","info":"misconfiguration error: the proxy is running in"

Also, if I already have a kube-state-metrics deployment installed in the cluster by Lens or another monitoring system, and the Zabbix helm chart wants to install Zabbix's  own kube-state-metrics, is this OK? This should be documented too.

Also, if the new Kubernetes templates are declared to be agentless (i.e. use the Kubernetes API), why does the Helm chart install a Zabbix agent? Or have I misunderstood the part about being agentless?

The documentation could be better, for sure. You've probably figured out the answers to some of these questions over the past year, but I'm answering them for anyone else who might happen to stumble across this ticket.

Users who does not want zabbix agents to monitor the host OS of the individual nodes in the cluster should disable the agent in values.yaml. (zabbixAgent.enabled=false) Likewise, anyone who already has a Zabbix proxy installed in their cluster by hand and does not want Helm to spin up and manage a separate Zabbix proxy should disable the proxy. (zabbixProxy.enabled=false)

rbac should be left enabled at a minimum for anyone who wants to use the "Kubernetes cluster state by HTTP" template.

> why does the Helm chart install a Zabbix agent?

The "Kubernetes cluster state by HTTP" template does not rely on the agent in any way. It is the template that most users are probably looking for. It monitors the state of various objects within the Kubernetes cluster and relies on the serviceAccount created by the Helm chart. (zabbix-service-account)

The "Kubernetes nodes by HTTP" template is the one that makes use of the Zabbix agent. It is used for monitoring the host OS of the individual nodes in the cluster. This template should only be used by teams who are responsible for managing the health of the underlying node OS. The template is problematic for customers of managed Kubernetes clusters as they are unlikely to have sufficient permissions for the default values of the chart. Some of those problematic features can be toggled in values.yaml (hostPID, hostNetwork, hostRootFsMount), but the most likely result from such users following the documentation is a non-functional DaemonSet for the zabbix agents. When in doubt: do not use this monitoring template, and disable the installation of the agent in values.yaml before running the Helm chart. (zabbixAgent.enabled=false)

> if I already have a kube-state-metrics deployment installed in the cluster by Lens or another monitoring system, and the Zabbix helm chart wants to install Zabbix's  own kube-state-metrics, is this OK?

"Probably", but you would need to make sure that the service is accessible from the namespace that your Zabbix containers were installed into. It would need to be the version that the monitoring template is expecting at minimum (2.2.0 as I write this), and if you are using a more recent version you are relying on there not being any breaking changes that would impact the monitoring template. It's simplest to let the chart install its own copy at the end of the day. If you deviate here, you are assuming ownership of any compatibility problems, and I can understand why the Zabbix developers would not go into any detail on this particular topic.

It would also be worthwhile to document the supported versions of kube-state-metrics explicitly, similar to what can be found in the Zabbix documentation for its server component. This would make it more feasible to disable the automatic installation of kube-state-metrics and maintain the dependency separately. It would also be handy when the dependency information for kube-state-metrics in the helm chart is stale, and Zabbix admins have vulnerability management teams breathing down their necks (see ZBX-22806).

The minimum configuration that is required is to change "zabbixProxy.env.ZBX_SERVER_HOST" to the address of Zabbix server that is used for monitoring. Other parameters can be changed in case of specific environment requirements but that assumes that user knows what he's doing.

You can use kube-state-metrics that was already deployed, but if it's configuration deviates from the default values, it may affect the set of metrics that is available, so you do that at your own risk as well. Same applies to the version. The set of metrics that is used in templates is supported since KSM 2.2.0 up to the current version (2.9.2) and hasn't degraded since then. We will update it on regular basis. The project documentation recommends to use the latest release. For additional information about compatibility with your cluster you can check the project's documentation.

Documentation is updated in:

• release/6.0: ea3128dd140
• release/6.4: f1dfafb615b
• master(7.0plan): 366470b29b6