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:
- Creating a Kubernetes Environment in Resource Management Mode
- Creating a VM + Kubernetes Environment in Resource Management Mode
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

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

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. Select an AZ from the AZ drop-down list. Select a CCE cluster that can be bound in the AZ from the Cluster drop-down list. Click OK. Click Add Cluster. Select another AZ from the AZ drop-down list. Select a CCE cluster that can be bound in the AZ from the Cluster drop-down list. 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. Set Cluster Source. Select CCE cluster and go to 2. Select Custom Kubernetes cluster and go to 4. Select the cluster to be bound from the Cluster drop-down list. (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. 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 (-). Click Import YAML File to import the kubeconfig file in YAML format. 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

Log in to ServiceStage.
Choose Environment Management. The Environment Management page is displayed.
Click the target environment. The Overview page is displayed.
Choose Clusters from Compute.
Click Edit Cluster.
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 (-).
Click Import YAML File to import the kubeconfig file in YAML format.
Click OK.