package k8s_tester.test_cluster_config

Get desktop application:
View/edit binary Protocol Buffers messages

Cluster holds the created cluster and its credential file.

Used in: TestRange

• string cluster = 1

  Cluster name.

• string kubectl_config = 2

  A kubectl config file that can be used to connect to the cluster.

• string kubectl_context = 3

  The kubectl context name within `kubectl_config` to use to connect to the cluster. If empty, the default context will be used.

• string gcp_project_id = 4

  The GCP project ID that the cluster is in. Optional; only used for cluster management tasks (e.g. deletion). Leave empty for non-GCP clusters.

• string gcp_location = 5

  The GCP location that the cluster is created in. Optional; only used for cluster management tasks (e.g. deletion). Leave empty for non-GCP clusters.

NodePool represents a set of Kubernetes nodes.

Used in: TestRangeSpec

• optional google.protobuf.Any node_pool = 1

  Opaque implementation-specific nodepool config. In GKE, this is a google.container.v1.NodePool.

TestRange contains the created clusters. This is an output from the setup phase and an input for the test phase.

• repeated Cluster clusters = 1

TestRangeSpec is a description of the test environment to be created. It is the input of the setup step which creates the required clusters.

• string name = 1

  Name for clusters. This name will be used as a template for all created clusters (e.g. my-cluster will have clusters named something like "my-cluster-0" with an ascending index). Cluster names are limited to 40 characters, so names will be truncated to fit this constraint.

• optional NodePool test_runtime = 2

  A nodepool built with the runtime under test.

• optional NodePool clients = 3

  clients is another nodepool in the cluster to use against the test_runtime. For example, in most client-server tests, the runtime under test is the server and the clients are the client. Clients always use the default runtime runc.

• optional NodePool tertiary = 8

  tertiary is a third nodepool in the cluster, used by some benchmarks that need it for isolation. For example, the WordPress benchmark needs to run the MySQL database on a separate machine in order to force network traffic to flow across the host's non-local network stack for a fair comparison between runsc/runc. The tertiary nodepool may use gVisor or runc as a runtime, depending on user configuration.

• repeated string versions = 4

  versions are the GKE patch versions to use for the clusters. The number of clusters created will be num(versions) * replicas.

• repeated string zones = 5

  zones are the availability zones in which to create clusters. clusters will be created in each zone in a round robin fashion until the requested amount of clusters is created. This is provided to expand quota. Note: please check that given zones actual have resources available (e.g ARM machines are not available in all zones).

• string project = 6

  project is the project under which clusters should be created.

• string gke_service_account = 7

  project service account to use to create clusters.