Google Kubernetes Engine (GKE) data - Adaptive Applications - BlueCat Gateway - 25.3

Cloud Discovery & Visibility Administration Guide
ft:locale
en-US
Product name
BlueCat Gateway
Version
25.3

Cloud Discovery & Visibility (CDV) supports discovery of Kubernetes resources within an Google Kubernetes Engine (GKE). When discovering GKEs, within BlueCat Address Manager (BAM) a new Configuration is created for each cluster. Pods and services are imported as devices. CDV can also optionally discover resources internal to an GKE Cluster (currently only pods and services, which are imported as devices). If you are discovering internal Kubernetes resources, CDV will also create a new Configuration for each Kubernetes cluster to hold that cluster's pods and services.

Tip: You can configure the discovery of GKE resources when creating a new GCP discovery by using the Advanced setup option (by default, GKE discovery is enabled in Basic setup). Alternatively, you can configure it after the discovery has been created. To configure discovery of GKE resources on an existing discovery, select the checkbox for the discovery in the Discovery page, then click Actions > Update options. In the Update options dialog that is displayed, go to the GCP Kubernetes section and edit the settings.

When CDV imports internal Kubernetes resources (pods and services), it creates separate Configurations for each Kubernetes cluster and imports each cluster's resources the appropriate Configuration. These Configurations are distinct from standard and overlapping Configurations.

CDV updates internal GKE resources as follows:

  • During Discovery, CDV updates the list of pods and services within a GKE Cluster.

  • Due to logging limitations on the GCP platform, CDV cannot run Visibility on internal Kubernetes resources (pods and services).

When CDV imports GKE data into Address Manager, it is imported as a hierarchy of tags based on the region, cluster, and node group of the GKE data.



The tag hierarchiy in Address Manager is as follows:
  • Tag Group: named as Google Kubernetes Engine to distinguish GKE data from other resource tags.
  • Level 1 tag: named as the Project Name in GCP to distinguish cluster and node pool tags from other resource groups.
  • Level 2 tag: named as the BlueCat configuration name. Since tags are used across configurations, using the name of the BlueCat configuration avoids data conflict and mismatches when multiple discovery and visibility requests are run against resources on the same Address Manager.
  • Level 3 tag: named as the cluster name.
  • Level 4 tag: named as the node pool name.

GKE Cluster data

In this example, the following GKE clusters have been created in the GCP infrastructure.



When imported into Address Manager, a GKE cluster is represented by a device with the Kubernetes Cluster device subtype.



Within the GCP infrastructure, each GKE cluster is registered with a VPC. To represent this relationship in Address Manager, CDV creates a tag with the same name as the GKE Cluster Device and links it to the corresponding address space.



GKE node pool data

In the following example, a node pool was added to an existing GKE cluster in the GCP infrastructure.



When imported into Address Manager, a GKE node pool is represented by a tag. The node pool tag is added to the associated GKE cluster device.



Within the GCP infrastructure, a node pool manages one or more VM instances. If you enable the discovery of VM instances, node pools tagged to the VM instance device are also imported.



Pods and services

CDV imports internal Kubernetes resources (pods and services) into BAM as devices, with their DNS records. CDV also creates a separate Configuration for each Kubernetes cluster to store each cluster's pods and services.

For example, a Kubernetes Configuration for two clusters, cluster-1 and cluster-2:



Blocks of of pods and services:



Pod and service devices: