- Function Overview
- Product Bulletin
- Service Overview
- Billing
- Getting Started
-
User Guide
- Clusters
- Workloads
- Network
- Storage
- O&M
- Namespaces
- ConfigMaps and Secrets
- Auto Scaling
- Add-ons
- Helm Chart
- Permissions
- Settings
- Best Practices
-
API Reference
- Before You Start
- API Overview
- Calling APIs
-
APIs
- Autopilot Cluster Management
- Add-on Management for Autopilot Clusters
-
Autopilot Cluster Upgrade
- Upgrading a Cluster
- Obtaining Cluster Upgrade Task Details
- Retrying a Cluster Upgrade Task
- Obtaining a List of Cluster Upgrade Task Details
- Performing a Pre-upgrade Check for a Cluster
- Obtaining Details About a Pre-upgrade Check Task of a Cluster
- Obtaining a List of Pre-upgrade Check Tasks of a Cluster
- Performing a Post-upgrade Check for a Cluster
- Backing Up a Cluster
- Obtaining a List of Cluster Backup Task Details
- Obtaining the Cluster Upgrade Information
- Obtaining a Cluster Upgrade Path
- Obtaining the Configuration of Cluster Upgrade Feature Gates
- Enabling the Cluster Upgrade Process Booting Task
- Obtaining a List of Upgrade Workflows
- Obtaining Details About a Specified Cluster Upgrade Booting Task
- Updating the Status of a Specified Cluster Upgrade Booting Task
- Quota Management for Autopilot Clusters
- Tag Management for Autopilot Clusters
-
Chart Management for Autopilot Clusters
- Uploading a Chart
- Obtaining a Chart List
- Obtaining a Release List
- Creating a Release
- Updating a Chart
- Deleting a Chart
- Updating a Release
- Obtaining a Chart
- Deleting a Release
- Obtaining a Release
- Downloading a Chart
- Obtaining Chart Values
- Obtaining Historical Records of a Release
- Obtaining the Quota of a User Chart
- Kubernetes APIs
- Permissions and Supported Actions
- Appendix
-
FAQs
- Billing
- Workloads
- Network Management
-
Storage
- Can PVs of the EVS Type in a CCE Autopilot Cluster Be Restored After They Are Deleted or Expire?
- What Can I Do If a Storage Volume Fails to Be Created?
- Can CCE Autopilot PVCs Detect Underlying Storage Faults?
- How Can I Delete the Underlying Storage If It Remains After a Dynamically Created PVC is Deleted?
- Permissions
- General Reference
Copied.
Using Third-Party Images
Scenario
CCE allows you to create workloads using images pulled from third-party image repositories.
Generally, a third-party image repository can only be accessed after authentication (using your username and password). CCE uses the secret-based authentication to pull images. You need to create a secret for an image repository before pulling images from the repository.
Prerequisites
CCE Autopilot can access the network where the private repository is located. There are two options for this:
- Access over a private network: Ensure that the VPC of the private repository is the same as the VPC where the cluster resides.
- Access over Direct Connect or VPN: Connect the private repository network to the VPC where the cluster resides through Direct Connect or VPN.
Using the Console
- Create a secret for accessing a third-party image repository.
Click the cluster name to access the cluster console. In the navigation pane on the left, choose ConfigMaps and Secrets. On the Secrets tab, click Create Secret in the upper right corner. Set Secret Type to kubernetes.io/dockerconfigjson. For details, see Creating a Secret.
Enter the username and password used to access the third-party image repository.
Figure 1 Creating a secret - When creating a workload, you can enter a private image path (such as domainname/namespace/imagename:tag) in Image Name and select the key created in 1.
Figure 2 Private image path
- Set other parameters and click Create Workload.
Using kubectl
- Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
- Use kubectl to create a secret of the kubernetes.io/dockerconfigjson.
kubectl create secret docker-registry myregistrykey -n default --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
In the preceding command, myregistrykey indicates the key name, default indicates the namespace where the key is located, and other parameters are as follows:
- DOCKER_REGISTRY_SERVER: address of a third-party image repository, for example, www.3rdregistry.com or 10.10.10.10:443
- DOCKER_USER: account used for logging in to a third-party image repository
- DOCKER_PASSWORD: password used for logging in to a third-party image repository
- DOCKER_EMAIL: email of a third-party image repository
- Use a third-party image to create a workload.
A kubernetes.io/dockerconfigjson secret is used for authentication when you obtain a private image. The following is an example of using the myregistrykey for authentication.
apiVersion: v1 kind: Pod metadata: name: foo namespace: default spec: containers: - name: foo image: www.3rdregistry.com/janedoe/awesomeapp:v1 imagePullSecrets: - name: myregistrykey #Use the created secret.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot