Categorygithub.com/openshift/origintestextendedcluster
package
4.1.0+incompatible
Repository: https://github.com/openshift/origin.git
Documentation: pkg.go.dev
Versions
2
Dependencies
28
Dependents
5
Files
1.2k SLOC

# README

Cluster Mirror

This document describes how to use the Cluster Mirror to create a Cluster Loader configuration of a local OpenShift cluster. Specifically the templates and pods that are contained in the various cluster namespaces.

The cluster mirror tool was conceived to provide a way to reproduce (with reasonably approximate fidelity) a control-plane workload. The idea is to make sure our scale testing efforts are as realistic as possible.

Use-cases include:

  • Replicating OpenShift Online clusters into lab environments for scale testing and R&D.
  • Reproducing customer environments in support situations.

Note: This tool does not inspect persistent storage, it does not look at the content of secrets and it does not export user data in any way. It takes a "fingerprint" of the target environment via API calls, and allows users to "replay" that environment elsewhere (in terms of number of namespaces, templates and pods and what type they are).

Running Cluster Mirror

Cluster Loader is implemented as an extended test in OpenShift, and thus is is distributed as a precompiled binary in the atomic-openshift-tests RPM.

Once you have the extended.test binary installed on your system, run:

$ export KUBECONFIG=${KUBECONFIG-$HOME/.kube/config}
$ ./extended.test --ginkgo.focus="Mirror cluster"

After the command completes there will be a file created in the current directory: cm.yml. This file can be then fed to the Cluster Loader command below to recreate various cluster objects that were mirrored.

The assumption for use with Cluster Loader is that the templates used in the source cluster have same filename in the quickstarts subdirectory (of current directory, relative to the cm.yml file).

Cluster Loader

Cluster Loader can take user generated OpenShift application configurations and load them onto an OpenShift cluster.

Running Cluster Loader

Cluster Loader is implemented as an extended test in OpenShift, and thus is is distributed as a precompiled binary in the atomic-openshift-tests RPM.

Once you have the extended.test binary installed on your system, run:

$ export KUBECONFIG=${KUBECONFIG-$HOME/.kube/config}
$ ./extended.test --ginkgo.focus="Load cluster" --viper-config=config/test

After the execution completes the cluster will have deployed the ojects defined in the configuration.

OpenShift.com -- Using Cluster Loader

# Packages

# Functions

CreateConfigmaps creates config maps from files in user defined namespaces.
CreatePods creates pods in user defined namespaces with user configurable tuning sets.
CreateSecrets creates secrets from files in user defined namespaces.
CreateTemplates creates templates in user defined namespaces with user configurable tuning sets.
GetTuningSet matches the name of the tuning set defined in the project and returns a pointer to the set.
InjectConfigMap modifies the pod struct and replaces the environment variables.
ParseConfig will complete flag parsing as well as viper tasks.
ParsePods unmarshalls the json file defined in the CL config into a struct.
Server is the webservice that will synchronize the start and stop of Pods.
SyncPods waits for pods to enter a state.
SyncRunningPods waits for pods to enter Running state.
SyncSucceededPods waits for pods to enter Completed state.

# Constants

# Variables

ConfigContext variable of type ContextType.

# Structs

ClusterLoaderObjectType is nested object type for cluster loader struct.
ClusterLoaderType struct only used for Cluster Loader test config.
ContextType is the root config struct.
PodCount struct keeps HTTP requst counts and state.
ServiceInfo struct to bundle env data.
SyncObjectType is nested object type for cluster loader synchronisation functionality.
TuningSetObjectType is shared struct for Pods & Templates.
TuningSetType is nested type for controlling Cluster Loader deployment pattern.