Updated on 2025-08-05 GMT+08:00

Binding a Cluster

Before creating a component based on a container in the Kubernetes or VM + Kubernetes environment, bind a cluster to the environment.

  • The VM + Kubernetes environment and Kubernetes non-HA environment support CCE and custom Kubernetes clusters.
  • The Kubernetes HA environment supports CCE clusters.

Restrictions

  • The CCE cluster must be a CCE Turbo Cluster or CCE Standard Cluster. For details, see CCE Cluster Types.

    If you create a CCE Turbo cluster, set SNAT rules for the cluster so that the cluster can access the public network through the NAT gateway to pull source code. Otherwise, when the source code is used to deploy a component in container-based deployment or a source code-build task is executed, the source code fails to be obtained because the public network cannot be accessed. As a result, the component deployment or build fails. For details about how to set SNAT rules for the cluster, see Accessing the Internet from a Container.

  • If IPv6 is enabled for the VPC where the target environment is located, select a CCE cluster with IPv6 enabled. Otherwise, the Java chassis microservice registered on the exclusive microservice engine with security authentication enabled in the VPC fails to register the discovery address using IPv6. For details, see What Should I Do If the Service Registration Fails After IPv6 Is Enabled for the Exclusive Microservice Engine with Security Authentication Enabled?

Prerequisites

  • You have created an environment. For details, see:
  • If you want to bind a CCE cluster, a CCE cluster in the Running state has been created, and the CCE cluster and environment must be in the same VPC.
    • For details about how to create a CCE cluster, see Buying a CCE Standard/Turbo Cluster. Create a CCE Turbo or CCE Standard cluster based on your service requirements.
      • For a Kubernetes HA environment, create a CCE cluster for each AZ.
      • For a Kubernetes non-HA environment or a VM + Kubernetes environment, create a CCE cluster.
    • For details about how to add a node to the CCE cluster, see Creating a Node.
      • CCE clusters support Elastic Cloud Server (VM) and BMS nodes.
      • For details about the OSs supported by CCE cluster nodes, see Node OS.
      • CCE cluster nodes support Docker and Containerd container engines. For details about relationship between node OSs and container engines, see Container Engine.
    • If you want to bind a custom Kubernetes cluster, a kubeconfig file in YAML format has been created. For details, see kubeconfig File Description.

Binding a CCE Cluster

  1. Log in to ServiceStage.
  2. Choose Environment Management. The Environment Management page is displayed.
  3. Click the target environment. The Overview page is displayed.
  4. Choose Clusters from Compute.

  5. Click Bind now.

    • For a Kubernetes environment, bind a cluster to the environment based on whether the environment is an HA environment. For details, see Table 1.
    • For a VM + Kubernetes environment, CCE clusters and custom Kubernetes clusters can be bound. For details about how to bind a cluster to a non-HA environment, see Table 1.
      Table 1 Binding a cluster

      HA Environment or Not

      How to Bind

      Yes

      Only CCE clusters can be bound.

      In an HA environment, the AZ where the master node of the cluster to be bound is located and the AZ where the nodes running workloads in the cluster are located must be the same as the AZ selected when the cluster is bound.

      1. Select an AZ from the AZ drop-down list.
      2. Select a CCE cluster that can be bound in the AZ from the Cluster drop-down list.
      3. Click OK.
      4. Click Add Cluster.
      5. Select another AZ from the AZ drop-down list.
      6. Select a CCE cluster that can be bound in the AZ from the Cluster drop-down list.
      7. Click OK.

        After the CCE cluster is bound, the cluster-created namespace default, existing namespaces, and new user-created namespaces are automatically bound. For details, see Managing Namespaces.

      No

      You can bind a CCE cluster or a custom Kubernetes cluster.

      1. Set Cluster Source.
        • Select CCE cluster and go to 2.
        • Select Custom Kubernetes cluster and go to 4.
      2. Select the cluster to be bound from the Cluster drop-down list.
      3. (Optional) Select the namespace to be bound to the CCE cluster from the Namespace drop-down list, and go to 6.
        • If no namespace is selected, after the CCE cluster is bound, the cluster-created namespace default, existing namespaces, and new user-created namespaces are automatically bound.
        • If a namespace is selected, the selected namespace is bound after the CCE cluster is bound. For details, see Managing Namespaces.
      4. Enter a cluster name.

        Enter 2 to 64 case-sensitive characters. Start with a letter and end with a letter or digit. Only use letters, digits, underscores (_), and hyphens (-).

      5. Click Import YAML File to import the kubeconfig file in YAML format.
      6. Click OK.

      If you have performed Installing Sermant Injector for the cluster, manage the ServiceComb engine or registry/configuration center associated with the installed Sermant Injector plug-in in the environment. Otherwise, the Sermant Injector plug-in will be unavailable in this environment.

      For details, see Managing Basic Resources.

    • If no CCE cluster is created, go to the CCE console as prompted, create a CCE cluster by referring to Prerequisites, and bind the CCE cluster.

Follow-up Operations

  • On the Overview page, click the Node List tab to view details about each node in the CCE cluster.
  • On the Overview page, click the Namespace tab to manage cluster namespaces by referring to Managing Namespaces.
  • On the Overview page, click the ConfigMaps tab to manage cluster configuration items by referring to Managing Configuration Items.
  • On the Overview page, click the Secrets tab to manage cluster secrets by referring to Managing Secrets.
  • On the Overview page, click View Resource Details to view cluster details on the CCE console.
  • On the Overview page, you can edit the custom Kubernetes cluster bound to a Kubernetes non-HA environment or a VM+Kubernetes environment by referring to Editing a Bound Custom Kubernetes Cluster.
  • On the Plug-in Management page, you can manage cluster plug-ins by referring to Managing Plug-ins.
  • If the cluster bound to the environment is no longer used, unbind the cluster by referring to Unbinding a Cluster.

kubeconfig File Description

Only use the kubeconfig file from reliable sources to prevent malicious code execution or file exposure.

It is a common way to manage a native Kubernetes cluster using the kubeconfig file. The kubeconfig file contains the configuration information required for the client to communicate with the Kubernetes cluster, including the cluster information, user authentication information, and context information.

Example kubeconfig file structure:

apiVersion: v1
kind: Config
preferences: {}
current-context: dev-context
clusters:
- name: my-cluster
  cluster:
    server: https://api.example.com:6443
    certificate-authority-data: LS0tLS1CRUd...  # Base64-encoded CA certificate
users:
- name: admin-user
  user:
    client-certificate-data: LS0tLS1CRUd...    # Base64-encoded client certificate
    client-key-data: LS0tLS1CRUd...            # Base64-encoded client private key
contexts:
- name: dev-context
  context:
    cluster: my-cluster
    user: admin-user
    namespace: default

For details, see Table 2.

Table 2 Parameters in the kubeconfig file

Parameter

Mandatory

Type

Description

Example Value

apiVersion

Yes

String

API version of the kubeconfig file.

v1

kind

Yes

String

Resource type of the kubeconfig file. The value is fixed at Config.

Config

preferences

No

Object

User preference settings (such as the output format and color).

{}

current-context

No

String

Name of the current context.

dev-context

clusters

Yes

Array of objects

Cluster list, which defines the cluster address and authentication information. For details, see Table 3.

-

users

Yes

Array of objects

User list, which defines the user authentication mode (such as certificate, token, username and password, and plug-in). For details, see Table 5.

-

contexts

Yes

Array

Context list, which associates clusters, users, and default namespaces. For details, see Table 8.

-

Table 3 clusters

Parameter

Mandatory

Type

Detail

Example Value

name

Yes

String

Unique cluster name.

my-cluster

cluster

Yes

Array

Cluster connection information. For details, see Table 4.

-

Table 4 cluster

Parameter

Mandatory

Type

Detail

Example Value

server

Yes

String

API server address of the cluster, which must contain the protocol and port number and can be accessed from the public network.

https://api.example.com:6443

certificate-authority

No

String

Path of the CA certificate file. Either this parameter or certificate-authority-data must be specified.

etc/kubernetes/pki/ca.crt

certificate-authority-data

No

String

Base64-encoded CA certificate data. Either this parameter or certificate-authority must be specified.

LS0tLS1CRUd...

insecure-skip-tls-verify

No

Boolean

Whether to skip TLS verification. This parameter is used only in the test environment.

false

Table 5 users

Parameter

Mandatory

Type

Detail

Example Value

name

Yes

String

Unique user name (customized).

admin-user

user

No

Array of objects

Defines the credential and mode for user identity authentication. Multiple authentication mechanisms (such as certificates, tokens, and dynamic plug-ins) are supported. For details, see Table 6.

-

Table 6 user

Parameter

Mandatory

Type

Detail

Example Value

client-certificate

No

String

Path of the client certificate file. Either this parameter or client-certificate-data must be specified.

/path/to/client.crt

client-certificate-data

No

String

Base64-encoded client certificate data. Either this parameter or client-certificate must be specified.

LS0tLS1CRUd...

client-key

No

String

Path of the client private key file. Either this parameter or client-key-data must be specified.

/path/to/client.key

client-key-data

No

String

Base64-encoded client private key data. Either this parameter or client-key must be specified.

LS0tLS1CRUd...

token

No

String

Static token (bearer token authentication)

eyJhbGciOiJSUzI1NiIsIm...

username

No

String

Basic authentication username.

admin

password

No

String

Basic authentication password.

secret

exec

No

Object

Dynamic authentication plug-in configuration. For details, see Table 7.

-

Table 7 exec

Parameter

Mandatory

Type

Detail

Example Value

apiVersion

Yes

String

API version of the exec plug-in.

client.authentication.k8s.io/v1beta1

command

Yes

String

Path of the executable command.

/usr/bin/aws-iam-authenticator

args

No

Array of String

Command parameter.

["token", "-i", "my-cluster"]

env

No

Object

Environment variable list.

{name: "AWS_PROFILE", value: "prod"}

Table 8 contexts

Parameter

Mandatory

Type

Detail

Example Value

name

Yes

String

Unique name of the context (customized).

dev-context

context

Yes

Array

Binds a cluster, user, and namespace to define a specific operating environment. You can switch between different contexts to quickly switch between different clusters, users, or namespaces. For details, see Table 9.

-

Table 9 context

Parameter

Mandatory

Type

Detail

Example Value

cluster

Yes

String

Name of the associated cluster. The value must be the same as name in Table 3.

my-cluster

user

Yes

String

Name of the associated user. The value must be the same as name in Table 5.

admin-user

namespace

No

String

Default namespace. If this parameter is not specified, default is used.

default

Editing a Bound Custom Kubernetes Cluster

  1. Log in to ServiceStage.
  2. Choose Environment Management. The Environment Management page is displayed.
  3. Click the target environment. The Overview page is displayed.
  4. Choose Clusters from Compute.
  5. Click Edit Cluster.
  6. Change the Cluster Name.

    Enter 2 to 64 case-sensitive characters. Start with a letter and end with a letter or digit. Only use letters, digits, underscores (_), and hyphens (-).

  7. Click Import YAML File to import the kubeconfig file in YAML format.
  8. Click OK.