Discovering from Kubernetes

The following types are used for Kubernetes discovery, all available in the AMP Catalog.

Entities

kubernetes-discovery

The main discovery entity. This connects to a KubernetesLocation and discovers all resources created under a particular namespace. The following configuration keys are available:

• namespace - The Kubernetes namespace to use when searching for resources.
• kubernetes.auto-organize-labels - Whether to automatically arrange discovered entities in a hierarchy based on the values of common Kubernetes labels. This defaults to true.
• kubernetes.health-check.period - The period between discovery status update checks. This defaults to 1 minute.

Discovered Groups

These represent groups of Kubernetes resources that have been discovered. These groups contain the discovered entities and are updated by the main discovery entity.

Discovered Entities

These represent individual Kubernetes resources, such as Pods or Services. Status of these resources is updated based on the discovered groupings, and they can be managed using effectors defined on the entities. Data about the current state of the entity are also exposed as sensor values, which can be used for checking compliance or other configuration.

Effectors available include:

• resize() - change the size of a resource, such as a ReplicaSet
• delete() - remove a resource completely, such as a Pod
• restart() - refresh a resource by restarting its components

Note If the properties of a discovered entity are changed in AMP, such as the display name, then this change will not be reflected back to the running resources. Entity manipulation should only be via effectors.

Predicates

These predicates are available to structure the discovered Kubernetes resource entities into groups based on various properties they have.

kubernetes-discovery-predicate-is-pod

This predicate will restrict the group to entities representing a Kubernetes Pod and is used as follows:

- $brooklyn:object:
    type: kubernetes-discovery-predicate-is-pod

kubernetes-discovery-predicate-has-label

This predicate takes two parameters, first the label name, and secondly the string to be matched. It will limit the entities to those with the specified label having a value matching the one provided.

The following will match resources with the label owner having the value brooklyn:

- $brooklyn:object:
    type: kubernetes-discovery-predicate-has-label
    constructor.args:
      - "owner"
      - "brooklyn"

kubernetes-discovery-predicate-name-matches

This predicate takes a regex value and will limit entities to those with a name matching the regex parameter. See the Java documentation for details of the syntax accepted.

The following will match any name beginning either foo1bar or foo2bar:

- $brooklyn:object:
    type: kubernetes-discovery-predicate-name-matches
    constructor.args:
      - "^foo[12]bar"

Initializers

kubernetes-labels-compliance-check

This initializer adds a compliance check to the AMP dashboard that verifies whether the discovered entities are using the suggested common labels from the Kubernetes documentation, as is best practice when creating Kubernetes applications. The following configuration keys are available:

• kubernetes.default-labels - Whether to check for the set of common Kubernetes label groups. This defaults to true.
• custom.labels - Supplies an additional list of extra labels to check for.
• labels-check.enabled - Enables the labels check for all discovered resources. This defaults to true, and should not normally need to be reconfigured.

The common labels are split into two groups, Application and Management, and any custom labels will be checked in a group named Custom. The initializer would typically be configured as follows, which specifies two extra custom labels.

brooklyn.initializers:
  - type: kubernetes-labels-compliance-check
    brooklyn.config:
      kubernetes.default-labels: true
      custom.labels: [ "io.cloudsoft/application-id", "io.cloudsoft/entity-id" ]