Using Third-Party Images

The following are operations for you to create a secret on the console and pull a third-party image to create a workload.

1. If the third-party image repository has an account and password, create a secret in the cluster as the identity credential for pulling images.
   1. Log in to the CCE console and click the cluster name to access the cluster console.
   2. In the navigation pane, choose ConfigMaps and Secrets. On the Secrets tab, click Create Secret.
   3. In the Create Secret dialog box, configure the parameters based on Figure 1 and Table 1. For more information about secrets, see Creating a Secret.
   Figure 1 Creating a secret
   

   Table 1 Parameters for creating a secret

   Parameter	Example Value	Description
   Name	test	Name for the secret. Enter up to 253 characters, starting and ending with a lowercase letter or digit. Only lowercase letters, digits, hyphens (-), and periods (.) are allowed.
   Secret Type	kubernetes.io/dockerconfigjson	Type of the secret. The value is fixed at kubernetes.io/dockerconfigjson, indicating that the secret is used for authentication when third-party images are pulled.
   Data	Image Repository Address: www.example.com Username: ssl Password: xxx	Image Repository Address: Enter the address of the third-party image repository. Username: Enter the username for accessing the third-party image repository. Password: Enter the password for accessing the third-party image repository.

2. In the navigation pane, choose Workloads. In the upper right corner of the displayed page, click Create Workload. On the Create Workload page, set Image Name (Container Settings > Container Information > Basic Info) to the third-party image path. Select the secret created in 1 for Image Access Credential.
   Figure 2 Third-party image path
   

3. (This step is required only when you need to configure an EIP for a pod.) Add an annotation (Advanced Settings > Labels and Annotations > Pod Annotation) based on Table 2. In this example, the pod's EIP uses a dedicated bandwidth. If you need to configure an EIP with a shared bandwidth, see Configuring an EIP for a Pod.
   Figure 3 Adding an annotation
   

   Table 2 Annotation for an EIP with a dedicated bandwidth

   Annotation	Mandatory	Default Value	Description	Value
   yangtse.io/pod-with-eip	Yes	false	Whether to bind an EIP to a pod	false or true
   yangtse.io/eip-bandwidth-size	No	5	Bandwidth, in Mbit/s	The value range varies depending on the region and bandwidth billing mode. For details, see the purchase page on the EIP console. For example, in the CN East-Shanghai1 region, if an EIP is billed by bandwidth, the bandwidth ranges from 1 Mbit/s to 2,000 Mbit/s; if an EIP is billed by traffic, the bandwidth ranges from 1 Mbit/s to 300 Mbit/s.
   yangtse.io/eip-network-type	No	5_bgp	EIP type	The types vary by region. For details, see the EIP console. For example, the following types are supported in the CN East-Shanghai1 region: 5_bgp: dynamic BGP 5_sbgp: static BGP
   yangtse.io/eip-charge-mode	No	None	Billed by traffic or bandwidth You are advised to configure this parameter. If this parameter is left blank, no billing mode is specified. In this case, the default value of the EIP API in the region is used.	bandwidth: billed by bandwidth traffic: billed by traffic
   yangtse.io/eip-bandwidth-name	No	Pod name	Bandwidth name	Enter 1 to 64 characters. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.

4. Configure other parameters and click Create Workload. If the workload status changes to Running, the third-party image is successfully pulled.

The following are operations for you to create a secret using kubectl and pull a third-party image to create a workload.

1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
2. If the third-party image repository has an account and password, you need to create a secret in the cluster as the identity credential for pulling images.
   1. Create a secret. The secret type is kubernetes.io/dockerconfigjson by default, which indicates that the secret is used for authentication when third-party images are pulled.

      kubectl create secret docker-registry test  -n default --docker-server=www.example.com --docker-username=ssl --docker-password=xxx --docker-email=example@123.com

      In the command, test indicates the secret name, default indicates the namespace where the secret is located, and other parameters are described in the following table.

      Table 3 Secret parameters

      Parameter	Example Value	Description
      docker-server	www.example.com	Enter the address of the third image repository.
      docker-username	ssl	Enter the username for accessing the third-party image repository.
      docker-password	xxx	Enter the password for accessing the third-party image repository.
      docker-email	example@123.com	Email address of the third-party image repository. This parameter is optional.

      Information similar to the following is displayed:

      secret/test created

   2. Check whether the secret has been created.

      kubectl get secret

      If the following information is displayed, the secret has been created:

      NAME             TYPE                             DATA   AGE
      default-secret   kubernetes.io/dockerconfigjson   1      41h
      paas.elb         cfe/secure-opaque                1      41h
      test             kubernetes.io/dockerconfigjson   1      16s

3. Create a workload using a third-party image.
   1. Create a YAML file for creating a workload. In this example, the file name is deployment.yaml. You can change it as needed.

      vim deployment.yaml

      Example file content:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: foo
        namespace: default
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: foo
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: foo
            annotations:  # Parameters in annotations are involved only when an EIP is required for the pod.
              yangtse.io/eip-bandwidth-name: test
              yangtse.io/eip-bandwidth-size: '5'
              yangtse.io/eip-charge-mode: bandwidth
              yangtse.io/eip-network-type: 5_bgp
              yangtse.io/pod-with-eip: 'true'
          spec:
            containers:
            - image: www.example.com/janedoe/awesomeapp:v1    # Third-party image path
              imagePullPolicy: Always
              name: foo
            imagePullSecrets:
            - name: test   # Use the created secret for identity authentication when images are pulled.

      Parameters in annotations are involved only when an EIP is required for a pod. In this example, the EIP uses a dedicated bandwidth. If you need to configure an EIP with a shared bandwidth, see Configuring an EIP for a Pod.

      Table 4 Annotation for an EIP with a dedicated bandwidth

      Annotation	Mandatory	Default Value	Description	Value
      yangtse.io/pod-with-eip	Yes	false	Whether to bind an EIP to a pod	false or true
      yangtse.io/eip-bandwidth-size	No	5	Bandwidth, in Mbit/s	The value range varies depending on the region and bandwidth billing mode. For details, see the purchase page on the EIP console. For example, in the CN East-Shanghai1 region, if an EIP is billed by bandwidth, the bandwidth ranges from 1 Mbit/s to 2,000 Mbit/s; if an EIP is billed by traffic, the bandwidth ranges from 1 Mbit/s to 300 Mbit/s.
      yangtse.io/eip-network-type	No	5_bgp	EIP type	The types vary by region. For details, see the EIP console. For example, the following types are supported in the CN East-Shanghai1 region: 5_bgp: dynamic BGP 5_sbgp: static BGP
      yangtse.io/eip-charge-mode	No	None	Billed by traffic or bandwidth You are advised to configure this parameter. If this parameter is left blank, no billing mode is specified. In this case, the default value of the EIP API in the region is used.	bandwidth: billed by bandwidth traffic: billed by traffic
      yangtse.io/eip-bandwidth-name	No	Pod name	Bandwidth name	Enter 1 to 64 characters. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.

   2. Create the workload.

      kubectl create -f deployment.yaml

      If information similar to the following is displayed, the workload is being created:

      deployment.apps/foo created

   3. Check the workload status.

      kubectl get deployment

      If the value of READY is 1/1, the pod created for the workload is available. This means the workload has been created.

      NAME     READY   UP-TO-DATE   AVAILABLE   AGE
      foo      1/1     1            1           4m59s