#Using Alauda Container Platform Registry in Kubernetes Clusters

The Alauda Container Platform (ACP) Registry provides secure container image management for Kubernetes workloads.

#Registry Access Guidelines

• Internal Address Recommended: For images stored in the cluster's registry, always prioritize using the internal service address internal-docker-registry.cpaas-system.svc when deploying within the cluster. This ensures optimal network performance and avoids unnecessary external routing.
• External Address Usage: The external ingress domain (e.g. registry.cluster.local) is primarily intended for:
  • Image pushes/pulls from outside the cluster (e.g., developer machines, CI/CD systems)
  • Cluster-external operations requiring registry access

#Deploy Sample Application

1. Create an application named my-app in the my-ns namespace.
2. Store the application image in the registry at internal-docker-registry.cpaas-system.svc/my-ns/my-app:v1.
3. The default ServiceAccount in each namespace is automatically configured with an imagePullSecret for accessing images from internal-docker-registry.cpaas-system.svc.

Example Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-ns
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: main-container
        image: internal-docker-registry.cpaas-system.svc/my-ns/my-app:v1
        ports:
        - containerPort: 8080

#Cross-Namespace Access

To allow users from my-ns to pull images from shared-ns, the administrator of shared-ns can create a role binding to grant the necessary permissions.

#Example Role Binding

# Access images from shared namespace (requires permissions)
kubectl create rolebinding cross-ns-pull \
  --clusterrole=system:image-puller \
  --serviceaccount=my-ns:default \
  -n shared-ns

#Best Practices

• Registry Usage: Always use internal-docker-registry.cpaas-system.svc for deployments to ensure security and performance.
• Namespace Isolation: Leverage namespace isolation for better security and management of images.
  • Use namespace-based image paths: internal-docker-registry.cpaas-system.svc/<namespace>/<image>:<tag>.
• Access Control: Use role bindings to manage cross-namespace access for users and service accounts.

#Verification Checklist

1. Validate image accessibility for the default ServiceAccount in my-ns:

kubectl auth can-i get images.registry.alauda.io --namespace my-ns --as=system:serviceaccount:my-ns:default

2. Validate image accessibility for a user in my-ns:

kubectl auth can-i get images.registry.alauda.io --namespace my-ns --as=<username>

#Troubleshooting

• Image Pull Errors: Check the imagePullSecrets in the pod spec and ensure they are correctly configured.
• Permission Denied: Ensure the user or ServiceAccount has the necessary role bindings in the target namespace.
• Network Issues: Verify network policies and service configurations to ensure connectivity to the internal registry.
• DNS Failures: Check the content of /etc/hosts file on the node, ensure DNS resolution for the internal-docker-registry.cpaas-system.svc is correctly configured.
  • Verify node's /etc/hosts configuration to ensure correct DNS resolution of internal-docker-registry.cpaas-system.svc
  • Example showing registry service mapping (ClusterIP of internal-docker-registry service):

    # /etc/hosts
    127.0.0.1   localhost localhost.localdomain
    10.4.216.11 internal-docker-registry.cpaas-system internal-docker-registry.cpaas-system.svc internal-docker-registry.cpaas-system.svc.cluster.local # cpaas-generated-node-resolver
  • How to get internal-docker-registry current ClusterIP:

    kubectl get svc -n cpaas-system internal-docker-registry -o jsonpath='{.spec.clusterIP}'