Refer to the GVC concepts page.
Refer to the Create a GVC guide for additional details.
Using the console, if an Org has multiple GVCs, there will be an angle bracket
> to the right of the current GVC name in
the left menu. Click the bracket to show and select a GVC.
The GVC namespace is used when constructing the canonical endpoint and individual location endpoints to avoid naming collision between workloads with the same name in different GVCs. The namespace is also used when performing service-to-service calls.
The cloud provider locations that workloads will be served from are mapped to a GVC. At least one location is required. The global and canonical endpoints will use DNS to route the request to the nearest healthy location.
Adding or removing a location will immediately provision or deprovision it from all workloads, respectively.
The available locations are scoped to an org and can be enabled/disabled globally. Any changes to the location at the org will be propagated to all GVCs using that location.
When a dedicated load balancer is enabled on a GVC, all inbound traffic is routed through a custom cloud load balancer for each enabled location. Enabling/disabling this option can cause a brief period when connectivity fails during the period of DNS propagation.
Additional charges apply when custom load balancing is enabled.
Any domains configured to route traffic to this GVC will also leverage the custom load balancer.
The following additional domain settings are available when using a custom load balancer:
If the image was pushed to the Control Plane registry for the same Org, no pull secret is required when a workload pulls from the image from the same Org .
Multiple pull secrets can be assigned to a GVC. A workload's container will use the appropriate secret when pulling the image from a private registry. If there are multiple secrets, the container will cycle through each one.
If authentication fails, the deployment will not be updated and the image pull will have an exponential backoff retry starting at 10 seconds and ending at 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.).
You may set environment variables at the GVC level, which can then be inherited by any of the GVC's workloads.
To inherit GVC environment variables, a container must have its
inheritEnv property set to true. For more information
about how environment variables work in Control Plane, please see the environment variables section of the workload reference page.
Once these tags are set, soft session affinity based on a cookie will consistently route requests to the same replica. The affinity to a particular replica will be lost if the replica restarts.
Tagslink in the middle context menu.
Tag Keytext box and enter the desired cookie name in the
Tag Valuetext box. Click
Tag Keytext box and enter the desired duration in the
Tag Valuetext box. Click
Execute the following CLI command (substitute the GVC_NAME, ORG_NAME, COOKIE_NAME, DURATION tokens) to add the requires Tags to a GVC:
copycpln gvc tag GVC_NAME --tag cpln/sessionCookie=COOKIE_NAME --tag cpln/sessionDuration=DURATION --org ORG_NAME
Using the console UI, when a GVC is selected, an
Export GVC link is available which will save (as a local multi-document YAML manifest file) the
GVC and all associated resources (Identities and Workloads).
Links to other resources are relative within the exported file. This allows the file to be easily used to backup and restore an entire GVC. It can also be used when promoting to other Orgs.
|create||Create new gvcs|
|delete||Delete existing gvcs|
|edit||Modify existing gvcs||view|
|manage||Full access||create, delete, edit, manage, view|
Displays the permissions granted to principals for the GVC.
Refer to the CLI documentation for a GVC.