Checking cluster health on VMware
You can use
apicup to check the health of the API Connect clusters in
your VMware deployment.
health-check command checks a number of criteria to determine the
health of their cluster. When all criteria are successfully met, the command displays no output, and
exits with a status of
0. When one or more criteria are not met, the command stops
processing and displays a message with the failure and exits with a status of
The command takes no arguments. The only option is the
--verbose is set the command prints all checks that were performed.
health-check is run against the namespace that is specified in
The health check is run on the specified subsystem.
The command verifies that for the specified subsystem:
apicupversion matches the API Connect release version.
- All cluster members are running the same API Connect release version.
- All cluster members have a deployment status of
- Docker is running.
- All Kubernetes-defined nodes are running.
- The Kubernetes Control Plane pods are running:
- The add-on Kubernetes Deployments are fulfilled:
- The add-on Kubernetes DaemonSets are fulfilled:
Usage: apicup subsys health-check <SUBSYS> [flags] Flags: -h, --help help for health-check --kubeconfig string (optional) absolute path to the kubeconfig file (default "/Users/<username>/.kube/config") -v, --verbose Verbose output Global Flags: --accept-license Accept the license for API Connect --debug Enable debug logging
Example usage, for a subsystem named
../apicup subsys health-check mgmt
- The command flag
--kubeconfig stringdoes not apply to deployments on VMware.
- In a multi-node OVA cluster, the
apicup subsys health-checkcommand does not return status information if a majority of the nodes are down. To obtain status information, start more nodes. Status is returned only when a quorum is achieved.
- Version 10.0.1.2-eus Known Limitation: Running
apicup subsys health-checkon 10.0.1.2-eus may result in some warning messages. The warnings are harmless and can be ignored. The warnings occur because the CRD version for some Kubernetes resources has been deprecated, but the resources have not been removed so are still supported. For example:
INFO Log level: info W0218 08:17:32.224850 424979 warnings.go:70] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition W0218 08:17:32.232455 424979 warnings.go:70] rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role W0218 08:17:32.237079 424979 warnings.go:70] rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding W0218 08:17:32.401830 424979 warnings.go:70] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition W0218 08:17:34.959226 424979 warnings.go:70] admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration W0218 08:17:34.962512 424979 warnings.go:70] admissionregistration.k8s.io/v1beta1 ValidatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 ValidatingWebhookConfiguration W0218 08:17:35.666316 424979 warnings.go:70] rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole