Skip to main content

Kubernetes API

Pack assets​

Preamble​

This Pack aims to monitor both the infrastructure layer (nodes) and the cluster services (deployments, daemonsets, etc) of a Kubernetes cluster. The Kubernetes API pack gives multiple choices regarding the way you can arrange cluster monitoring. There are mainly three ways:

  • Gather all metrics on only one Centreon host with a service per Kubernetes unit (i.e. deployments, daemonsets, etc) - apply manual creation procedure,
  • Gather all metrics on only one Centreon host with a service for each instance of each Kubernetes unit - apply manual creation and service discovery procedures,
  • Collect infrastructural metrics (master and worker nodes) with a Centreon host per Kubernetes node, and keep orchestration/application metrics on a unique host (using one of the 2 previous scenarios) - apply the host discovery procedure.

Templates​

The Monitoring Connector Kubernetes API brings 2 host templates:

  • Cloud-Kubernetes-Api-custom
  • Cloud-Kubernetes-Kubectl-custom
  • Cloud-Kubernetes-Node-Api-custom
  • Cloud-Kubernetes-Node-Kubectl-custom

The connector brings the following service templates (sorted by the host template they are attached to):

Service AliasService TemplateService DescriptionDiscovery
Cluster-EventsCloud-Kubernetes-Cluster-Events-Api-customCheck the number of events occurring in the cluster
CronJob-StatusCloud-Kubernetes-CronJob-Status-Api-customCheck CronJobs statusX
Daemonset-StatusCloud-Kubernetes-Daemonset-Status-Api-customCheck DaemonSets statusX
Deployment-StatusCloud-Kubernetes-Deployment-Status-Api-customCheck Deployments statusX
Node-StatusCloud-Kubernetes-Node-Status-Api-customCheck Nodes status
Node-StatusCloud-Kubernetes-Node-Status-Name-Api-customCheck status of a node identified by its name (for example at the end of the associated discovery rule)X
Node-UsageCloud-Kubernetes-Node-Usage-Api-customCheck nodes usage
Node-UsageCloud-Kubernetes-Node-Usage-Name-Api-customCheck the usage of a node identified by its name (for example at the end of the associated discovery rule)X
PersistentVolume-StatusCloud-Kubernetes-PersistentVolume-Status-Api-customCheck PersistentVolumes statusX
Pod-StatusCloud-Kubernetes-Pod-Status-Api-customCheck pods and containers statusX
ReplicaSet-StatusCloud-Kubernetes-ReplicaSet-Status-Api-customCheck ReplicaSets statusX
ReplicationController-StatusCloud-Kubernetes-ReplicationController-Status-Api-customCheck ReplicationControllers statusX
StatefulSet-StatusCloud-Kubernetes-StatefulSet-Status-Api-customCheck StatefulSets statusX

The services listed above are created automatically when the Cloud-Kubernetes-Api-custom host template is used.

If Discovery is checked, it means a service discovery rule exists for this service template.

Discovery rules​

Host discovery​

Rule nameDescription
Kubernetes Nodes (RestAPI)Discover Kubernetes nodes by requesting the Kubernetes RestAPI
Kubernetes Nodes (Kubectl)Discover Kubernetes nodes by requesting the Kubernetes cluster using kubectl

More information about discovering hosts automatically is available on the dedicated page.

Service discovery​

Rule nameDescription
Cloud-Kubernetes-Api-CronJobs-StatusDiscover Kubernetes CronJobs to monitor their status
Cloud-Kubernetes-Api-Daemonsets-StatusDiscover Kubernetes DaemonSets to monitor their status
Cloud-Kubernetes-Api-Deployments-StatusDiscover Kubernetes Deployments to monitor their status
Cloud-Kubernetes-Api-Nodes-StatusDiscover Kubernetes Nodes to monitor their status
Cloud-Kubernetes-Api-Nodes-UsageDiscover Kubernetes Nodes to monitor their usage
Cloud-Kubernetes-Api-PersistentVolumes-StatusDiscover Kubernetes PersistentVolumes to monitor their status
Cloud-Kubernetes-Api-Pods-StatusDiscover Kubernetes Pods to monitor their status
Cloud-Kubernetes-Api-ReplicaSets-StatusDiscover Kubernetes ReplicaSets to monitor their status
Cloud-Kubernetes-Api-ReplicationControllers-StatusDiscover Kubernetes ReplicationControllers to monitor their status
Cloud-Kubernetes-Api-StatefulSets-StatusDiscover Kubernetes StatefulSets to monitor their status

More information about discovering services automatically is available on the dedicated page and in the following chapter.

Collected metrics & status​

Here is the list of services for this connector, detailing all metrics linked to each service.

Metric nameUnit
events.type.warning.countcount
events.type.normal.countcount
events#statusN/A

Additional information on metrics and services​

This indicator allows you to watch the number of events occurring on the cluster. If the kubectl get events command has the following output:

NAMESPACE   LAST SEEN   TYPE      REASON      OBJECT           MESSAGE
graphite    26m         Warning   Unhealthy   pod/graphite-0   Liveness probe failed: Get "http://10.244.2.10:8080/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Then the resulting output in Centreon could look like:

Event 'Warning' for object 'Pod/graphite-0' with message 'Liveness probe failed: Get "http://10.244.2.10:8080/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)', Count: 1, First seen: 26m 21s ago (2021-03-11T12:26:23Z), Last seen: 26m 21s ago (2021-03-11T12:26:23Z)

Prerequisites​

As mentioned in the introduction, two ways of communication are available:

  • the RestAPI exposed by the Kubernetes cluster,
  • the CLI tool kubectl to communicate with the cluster's control plane.

For better performances, we recommend to use the RestAPI.

Create a service account​

Both flavors can use a service account with sufficient rights to access Kubernetes API.

Create a dedicated service account centreon-service-account in the kube-system namespace to access the API:

kubectl create serviceaccount centreon-service-account --namespace kube-system

Create a cluster role api-access with needed privileges for the Plugin, and bind it to the newly created service account:

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-access
rules:
  - apiGroups:
      - ""
      - apps
      - batch
    resources:
      - cronjobs
      - daemonsets
      - deployments
      - events
      - namespaces
      - nodes
      - persistentvolumes
      - pods
      - replicasets
      - replicationcontrollers
      - statefulsets
    verbs:
      - get
      - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-access
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-access
subjects:
- kind: ServiceAccount
  name: centreon-service-account
  namespace: kube-system
EOF

Refer to the official documentation for service account creation or information about secret concept.

Using RestAPI​

If you chose to communicate with your Kubernetes platform's RestAPI, the following prerequisites need to be matched:

  • Expose the API with TLS,
  • Retrieve token from service account.
Expose the API​

As the API is using HTTPS, you will need a certificate.

You can make an auto-signed key/certificate couple with the following command:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/kubernetesapi.key -out /etc/ssl/certs/kubernetesapi.crt

Then load it as api-certificate into the cluster, from the master node:

kubectl create secret tls api-certificate --key /etc/ssl/private/kubernetesapi.key --cert /etc/ssl/certs/kubernetesapi.crt

The ingress can now be created:

cat <<EOF | kubectl create -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetesapi-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
    - hosts:
    @@ -671,10 +671,13 @@ spec:
  - host: kubernetesapi.local.domain
    http:
      paths:
      - path: /
        pathType: ImplementationSpecific
        backend:
          service:
            name: kubernetes
            port:
              number: 443
EOF

Adapt the host entry to your needs.

Refer to the official documentation for ingresses management.

Retrieve token from service account​

Retrieve the secret name from the previously created service account:

kubectl get serviceaccount centreon-service-account --namespace kube-system --output jsonpath='{.secrets[].name}'

Then retrieve the token from the service account secret:

kubectl get secrets centreon-service-account-token-xqw7m --namespace kube-system --output jsonpath='{.data.token}' | base64 --decode

This token will be used later for Centreon host configuration.

Using kubectl​

If you chose to communicate with the cluster's control plane with kubectl, the following prerequisites need to be matched:

  • Install the kubectl tool,
  • Create a kubectl configuration.

Those actions are needed on all Pollers that will do Kubernetes monitoring.

Install kubectl​

Download the latest release with the following command:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

Be sure to download a version within one minor version difference of your cluster. To download a specific version, change the embedded curl in the command above by the version. For example if you want to download the version v1.20.0: curl -LO "https://dl.k8s.io/release/v1.20.0/bin/linux/amd64/kubectl"

Install the tool in the binaries directory:

sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

Refer to the official documentation for more details.

Create a kubectl configuration​

To access the cluster, kubectl needs a configuration file with all needed information.

Here is an example of a configuration file creation based on a service account (created in previous chapter).

You will need to fill the following information and execute the commands on the master node:

ip=<master node ip>
port=<api port>
account=centreon-service-account
namespace=kube-system
clustername=my-kube-cluster
context=my-kube-cluster
secret=$(kubectl get serviceaccount $account --namespace $namespace --output jsonpath='{.secrets[].name}')
ca=$(kubectl get secret $secret --namespace $namespace --output jsonpath='{.data.ca\.crt}')
token=$(kubectl get secret $secret --namespace $namespace --output jsonpath='{.data.token}' | base64 --decode)

The account name and namespace must match with the account created earlier. All others need to be adapted.

Then execute this command to generate the config file :

cat <<EOF >> config
apiVersion: v1
kind: Config
clusters:
- name: ${clustername}
  cluster:
    certificate-authority-data: ${ca}
    server: https://${ip}:${port}
contexts:
- name: ${context}
  context:
    cluster: ${clustername}
    namespace: ${namespace}
    user: ${account}
current-context: ${context}
users:
- name: ${account}
  user: ${token}
EOF

This will create a config file. This file must be copied to the Pollers Engine user's home, usually in a .kube directory (i.e. /var/lib/centreon-engine/.kube/config).

This path will be used later in Centreon host configuration.

You may also want to copy the configuration to Gorgone user's home if using Host Discovery.

Refer to the official documentation for more details.

Installing the monitoring connector​

Pack​

  1. If the platform uses an online license, you can skip the package installation instruction below as it is not required to have the connector displayed within the Configuration > Monitoring Connector Manager menu. If the platform uses an offline license, install the package on the central server with the command corresponding to the operating system's package manager:
dnf install centreon-pack-cloud-kubernetes-api
  1. Whatever the license type (online or offline), install the Kubernetes API connector through the Configuration > Monitoring Connector Manager menu.

Plugin​

Since Centreon 22.04, you can benefit from the 'Automatic plugin installation' feature. When this feature is enabled, you can skip the installation part below.

You still have to manually install the plugin on the poller(s) when:

  • Automatic plugin installation is turned off
  • You want to run a discovery job from a poller that doesn't monitor any resource of this kind yet

More information in the Installing the plugin section.

Use the commands below according to your operating system's package manager:

dnf install centreon-plugin-Cloud-Kubernetes-Api

Using the monitoring connector​

Using a host template provided by the connector​

  1. Log into Centreon and add a new host through Configuration > Hosts.
  2. Fill in the Name, Alias & IP Address/DNS fields according to your resource's settings.
  3. Apply the Cloud-Kubernetes-Api-custom template to the host. A list of macros appears. Macros allow you to define how the connector will connect to the resource, and to customize the connector's behavior.
  4. Fill in the macros you want. Some macros are mandatory, in particular the macro for defining the custom mode, i.e. the connection method to the resource.
MacroDescriptionDefault valueMandatory
KUBERNETESAPIHOSTNAMEHostname or address of the Kubernetes API serviceX
KUBERNETESAPITOKENToken retrieved from service accountX
KUBERNETESAPIPROTOSpecify https if neededhttps
KUBERNETESAPIPORTAPI port443
KUBERNETESAPICUSTOMMODEWhen a plugin offers several ways (CLI, library, etc.) to get information the desired one must be defined with this optionapi
KUBERNETESAPINAMESPACESet namespace to get informations
KUBERNETESNODENAMEFilter StatefulSet name (can be a regexp)
PROXYURLProxy URL if any
TIMEOUTSet timeout in seconds10
EXTRAOPTIONSAny extra option you may want to add to every command (a --verbose flag for example). All options are listed here.
  1. Deploy the configuration. The host appears in the list of hosts, and on the Resources Status page. The command that is sent by the connector is displayed in the details panel of the host: it shows the values of the macros.

    For the host discovery: set the token retrieved ealier from the service account,

Using a service template provided by the connector​

  1. If you have used a host template and checked Create Services linked to the Template too, the services linked to the template have been created automatically, using the corresponding service templates. Otherwise, create manually the services you want and apply a service template to them.
  2. Fill in the macros you want (e.g. to change the thresholds for the alerts). Some macros are mandatory (see the table below).
MacroDescriptionDefault valueMandatory
FILTERTYPEFilter event type (can be a regexp).*
FILTERNAMESPACEFilter namespace (can be a regexp).*
WARNINGSTATUSDefine the conditions to match for the status to be WARNING (default: '%{type} =~ /warning/i') Can use special variables like: %{name}, %{namespace}, %{type}, %{object}, %{message}, %{count}, %{first_seen}, %{last_seen}%{type} =~ /warning/i
CRITICALSTATUSDefine the conditions to match for the status to be CRITICAL (default: '%{type} =~ /error/i'). Can use special variables like: %{name}, %{namespace}, %{type}, %{object}, %{message}, %{count}, %{first_seen}, %{last_seen}%{type} =~ /error/i
EXTRAOPTIONSAny extra option you may want to add to the command (a --verbose flag for example). All options are listed here.--verbose
  1. Deploy the configuration. The service appears in the list of services, and on the Resources Status page. The command that is sent by the connector is displayed in the details panel of the service: it shows the values of the macros.

How to check in the CLI that the configuration is OK and what are the main options for?​

Once the plugin is installed, log into your Centreon poller's CLI using the centreon-engine user account (su - centreon-engine). Test that the connector is able to monitor a resource using a command like this one (replace the sample values by yours):

/usr/lib/centreon/plugins/centreon_kubernetes_api.pl \
    --plugin=cloud::kubernetes::plugin \
    --mode=statefulset-status \
    --custommode='api' \
    --hostname= \
    --port='443' \
    --proto='https' \
    --token='' \
    --config-file='' \
    --proxyurl='' \
    --namespace='' \
    --timeout='10'  \
    --filter-name='.*' \
    --filter-namespace='.*' \
    --warning-status='%{up_to_date} < %{desired}' \
    --critical-status='%{ready} < %{desired}' \
    --verbose

The expected command output is shown below:

OK: All StatefulSets status are ok |

Troubleshooting​

Here are some common errors and their description. You will often want to use the --debug option to get the root error.

ErrorDescription
UNKNOWN: Cannot decode json response: Can't connect to <hostname>:<port> (certificate verify failed)This error may appear if the TLS certificate is self-signed. Use the option --ssl-opt="SSL_verify_mode => SSL_VERIFY_NONE" to omit the certificate validity.
UNKNOWN: API return error code '401' (add --debug option for detailed message)If adding --debug option, API response message says Unauthorized. It generally means that the provided token is not valid.
UNKNOWN: API return error code '403' (add --debug option for detailed message)If adding --debug option, API response message says nodes is forbidden: User "system:serviceaccount:<namespace>:<account>" cannot list resource "nodes" in API group "" at the cluster scope. It means that the cluster role RBAC bound to the service account does not have the necessary privileges
UNKNOWN: CLI return error code '1' (add --debug option for detailed message)If adding --debug option, CLI response message says error: stat ~/.kube/config:: no such file or directory. The provided configuration file cannot be found.
UNKNOWN: CLI return error code '1' (add --debug option for detailed message)If adding --debug option, CLI response message says error: error loading config file "/root/.kube/config": open /root/.kube/config: permission denied. The provided configuration file cannot be read by current user.
UNKNOWN: CLI return error code '1' (add --debug option for detailed message)If adding --debug option, CLI response message says error: error loading config file "/root/.kube/config": v1.Config.AuthInfos: []v1.NamedAuthInfo: v1.NamedAuthInfo.AuthInfo: v1.AuthInfo.ClientKeyData: decode base64: illegal base64.... The provided configuration file is not valid.
UNKNOWN: CLI return error code '1' (add --debug option for detailed message)If adding --debug option, CLI response message says The connection to the server <hostname>:<port> was refused - did you specify the right host or port?. The provided configuration file is not valid.

For more cases, please find the troubleshooting documentation for the API-based plugins in this chapter.

Available modes​

In most cases, a mode corresponds to a service template. The mode appears in the execution command for the connector. In the Centreon interface, you don't need to specify a mode explicitly: its use is implied when you apply a service template. However, you will need to specify the correct mode for the template if you want to test the execution command for the connector in your terminal.

All available modes can be displayed by adding the --list-mode parameter to the command:

/usr/lib/centreon/plugins/centreon_kubernetes_api.pl \
    --plugin=cloud::kubernetes::plugin \
    --list-mode

The plugin brings the following modes:

ModeLinked service template
cluster-events [code]Cloud-Kubernetes-Cluster-Events-Api-custom
cronjob-status [code]Cloud-Kubernetes-CronJob-Status-Api-custom
daemonset-status [code]Cloud-Kubernetes-Daemonset-Status-Api-custom
deployment-status [code]Cloud-Kubernetes-Deployment-Status-Api-custom
discovery [code]Used for host discovery
list-cronjobs [code]Used for service discovery
list-daemonsets [code]Used for service discovery
list-deployments [code]Used for service discovery
list-ingresses [code]Not used in this Monitoring Connector
list-namespaces [code]Not used in this Monitoring Connector
list-nodes [code]Used for service discovery
list-persistentvolumes [code]Used for service discovery
list-pods [code]Used for service discovery
list-replicasets [code]Used for service discovery
list-replicationcontrollers [code]Used for service discovery
list-services [code]Not used in this Monitoring Connector
list-statefulsets [code]Used for service discovery
node-status [code]Cloud-Kubernetes-Node-Status-Api-custom
Cloud-Kubernetes-Node-Status-Name-Api-custom
node-usage [code]Cloud-Kubernetes-Node-Usage-Api-custom
Cloud-Kubernetes-Node-Usage-Name-Api-custom
persistentvolume-status [code]Cloud-Kubernetes-PersistentVolume-Status-Api-custom
pod-status [code]Cloud-Kubernetes-Pod-Status-Api-custom
replicaset-status [code]Cloud-Kubernetes-ReplicaSet-Status-Api-custom
replicationcontroller-status [code]Cloud-Kubernetes-ReplicationController-Status-Api-custom
statefulset-status [code]Cloud-Kubernetes-StatefulSet-Status-Api-custom

Available custom modes​

This connector offers several ways to connect to the resource (CLI, library, etc.), called custom modes. All available custom modes can be displayed by adding the --list-custommode parameter to the command:

/usr/lib/centreon/plugins/centreon_kubernetes_api.pl \
    --plugin=cloud::kubernetes::plugin \
    --list-custommode

The plugin brings the following custom modes:

  • api
  • kubectl

Available options​

Generic options​

All generic options are listed here:

OptionDescription
--modeDefine the mode in which you want the plugin to be executed (see--list-mode).
--dyn-modeSpecify a mode with the module's path (advanced).
--list-modeList all available modes.
--mode-versionCheck minimal version of mode. If not, unknown error.
--versionReturn the version of the plugin.
--custommodeWhen a plugin offers several ways (CLI, library, etc.) to get information the desired one must be defined with this option.
--list-custommodeList all available custom modes.
--multipleMultiple custom mode objects. This may be required by some specific modes (advanced).
--pass-managerDefine the password manager you want to use. Supported managers are: environment, file, keepass, hashicorpvault and teampass.
--verboseDisplay extended status information (long output).
--debugDisplay debug messages.
--filter-perfdataFilter perfdata that match the regexp. Example: adding --filter-perfdata='avg' will remove all metrics that do not contain 'avg' from performance data.
--filter-perfdata-advFilter perfdata based on a "if" condition using the following variables: label, value, unit, warning, critical, min, max. Variables must be written either %{variable} or %(variable). Example: adding --filter-perfdata-adv='not (%(value) == 0 and %(max) eq "")' will remove all metrics whose value equals 0 and that don't have a maximum value.
--explode-perfdata-maxCreate a new metric for each metric that comes with a maximum limit. The new metric will be named identically with a '_max' suffix). Example: it will split 'used_prct'=26.93%;0:80;0:90;0;100 into 'used_prct'=26.93%;0:80;0:90;0;100 'used_prct_max'=100%;;;;
--change-perfdata --extend-perfdataChange or extend perfdata. Syntax: --extend-perfdata=searchlabel,newlabel,target[,[newuom],[min],[m ax]] Common examples: Convert storage free perfdata into used: --change-perfdata='free,used,invert()' Convert storage free perfdata into used: --change-perfdata='used,free,invert()' Scale traffic values automatically: --change-perfdata='traffic,,scale(auto)' Scale traffic values in Mbps: --change-perfdata='traffic_in,,scale(Mbps),mbps' Change traffic values in percent: --change-perfdata='traffic_in,,percent()'
--extend-perfdata-groupAdd new aggregated metrics (min, max, average or sum) for groups of metrics defined by a regex match on the metrics' names. Syntax: --extend-perfdata-group=regex,namesofnewmetrics,calculation[,[ne wuom],[min],[max]] regex: regular expression namesofnewmetrics: how the new metrics' names are composed (can use $1, $2... for groups defined by () in regex). calculation: how the values of the new metrics should be calculated newuom (optional): unit of measure for the new metrics min (optional): lowest value the metrics can reach max (optional): highest value the metrics can reach Common examples: Sum wrong packets from all interfaces (with interface need --units-errors=absolute): --extend-perfdata-group=',packets_wrong,sum(packets_(discard |error)_(in|out))' Sum traffic by interface: --extend-perfdata-group='traffic_in_(.*),traffic_$1,sum(traf fic_(in|out)_$1)'
--change-short-output --change-long-outputModify the short/long output that is returned by the plugin. Syntax: --change-short-output=pattern~replacement~modifier Most commonly used modifiers are i (case insensitive) and g (replace all occurrences). Example: adding --change-short-output='OK~Up~gi' will replace all occurrences of 'OK', 'ok', 'Ok' or 'oK' with 'Up'
--change-exitReplace an exit code with one of your choice. Example: adding --change-exit=unknown=critical will result in a CRITICAL state instead of an UNKNOWN state.
--range-perfdataRewrite the ranges displayed in the perfdata. Accepted values: 0: nothing is changed. 1: if the lower value of the range is equal to 0, it is removed. 2: remove the thresholds from the perfdata.
--filter-uomMask the units when they don't match the given regular expression.
--opt-exitReplace the exit code in case of an execution error (i.e. wrong option provided, SSH connection refused, timeout, etc). Default: unknown.
--output-ignore-perfdataRemove all the metrics from the service. The service will still have a status and an output.
--output-ignore-labelRemove the status label ("OK:", "WARNING:", "UNKNOWN:", CRITICAL:") from the beginning of the output. Example: 'OK: Ram Total:...' will become 'Ram Total:...'
--output-xmlReturn the output in XML format (to send to an XML API).
--output-jsonReturn the output in JSON format (to send to a JSON API).
--output-openmetricsReturn the output in OpenMetrics format (to send to a tool expecting this format).
--output-fileWrite output in file (can be combined with json, xml and openmetrics options). E.g.: --output-file=/tmp/output.txt will write the output in /tmp/output.txt.
--disco-formatApplies only to modes beginning with 'list-'. Returns the list of available macros to configure a service discovery rule (formatted in XML).
--disco-showApplies only to modes beginning with 'list-'. Returns the list of discovered objects (formatted in XML) for service discovery.
--float-precisionDefine the float precision for thresholds (default: 8).
--source-encodingDefine the character encoding of the response sent by the monitored resource Default: 'UTF-8'. Kubernetes CLI (kubectl)
--namespaceSet namespace to get informations.
--timeoutSet timeout in seconds (default: 10).
--proxyurlProxy URL if any

Custom modes options​

All custom modes specific options are listed here:

OptionDescription
--hostnameKubernetes API hostname.
--portAPI port (default: 443)
--protoSpecify https if needed (default: 'https')
--timeoutSet HTTP timeout
--limitNumber of responses to return for each list calls. See https://kubernetes.io/docs/reference/kubernetes-api/common-param eters/common-parameters/#limit
--namespaceSet namespace to get information.
--legacy-api-betaIf this option is set the legacy API path are set for this API calls: kubernetes_list_cronjobs will use this path: /apis/batch/v1beta1/namespaces/ and kubernetes_list_ingresses will use this path: /apis/extensions/v1beta1/namespaces/ . This ways are no longer served since K8S 1.22 see https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122
--http-peer-addrSet the address you want to connect to. Useful if hostname is only a vhost, to avoid IP resolution.
--proxyurlProxy URL. Example: http://my.proxy:3128
--proxypacProxy pac file (can be a URL or a local file).
--insecureAccept insecure SSL connections.
--http-backendPerl library to use for HTTP transactions. Possible values are: lwp (default) and curl.
--ssl-optSet SSL Options (--ssl-opt="SSL_version => TLSv1" --ssl-opt="SSL_verify_mode => SSL_VERIFY_NONE").
--curl-optSet CURL Options (--curl-opt="CURLOPT_SSL_VERIFYPEER => 0" --curl-opt="CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_1" ).

Modes options​

All available options for each service template are listed below:

OptionDescription
--config-fileKubernetes configuration file path (default: '~/.kube/config'). (example: --config-file='/root/.kube/config').
--contextContext to use in configuration file.
--sudoUse 'sudo' to execute the command.
--commandCommand to get information (default: 'kubectl'). Can be changed if you have output in a file.
--command-pathCommand path (default: none).
--command-optionsCommand options (default: none).
--filter-typeFilter event type (can be a regexp).
--filter-namespaceFilter namespace (can be a regexp).
--warning-statusDefine the conditions to match for the status to be WARNING (default: '%{type} =~ /warning/i') Can use special variables like: %{name}, %{namespace}, %{type}, %{object}, %{message}, %{count}, %{first_seen}, %{last_seen}.
--critical-statusDefine the conditions to match for the status to be CRITICAL (default: '%{type} =~ /error/i'). Can use special variables like: %{name}, %{namespace}, %{type}, %{object}, %{message}, %{count}, %{first_seen}, %{last_seen}.

All available options for a given mode can be displayed by adding the --help parameter to the command:

/usr/lib/centreon/plugins/centreon_kubernetes_api.pl \
    --plugin=cloud::kubernetes::plugin \
    --mode=statefulset-status \
    --custommode='api' \
    --help