awslabs / amazon-eks-ami

Packer configuration for building a custom EKS AMI
https://awslabs.github.io/amazon-eks-ami/
MIT No Attribution
2.46k stars 1.15k forks source link

How to run with CredentialProvider in my EKS cluster? #1277

Closed czhczh0123 closed 1 year ago

czhczh0123 commented 1 year ago

Environment:

Environment: EKS cluster version 1.23 node image: ami-030d7615436dd9131

[root@ip-10-0-0-166 ~]# cat /etc/eks/ecr-credential-provider/ecr-credential-provider-config
apiVersion: kubelet.config.k8s.io/v1alpha1
kind: CredentialProviderConfig
providers:
  - name: ecr-credential-provider
    matchImages:
      - "*.dkr.ecr.*.amazonaws.com"
      - "*.dkr.ecr.*.amazonaws.cn"
      - "*.dkr.ecr-fips.*.amazonaws.com"
      - "*.dkr.ecr.us-iso-east-1.c2s.ic.gov"
      - "*.dkr.ecr.us-isob-east-1.sc2s.sgov.gov"
    defaultCacheDuration: "12h"
    apiVersion: credentialprovider.kubelet.k8s.io/v1alpha1
    args:
      - get-credentials

This is the default configuration file. Because my EKS cluster was launched in China region, so I added the following provider.

When I ran a new pod with the container image from my ECR repo, the pod could be launched without any issue. But checking the kubelet log, I could find the logs above.

Actually, if I did not change the default config file, I will not see the second message related to my ecr repo credentials.

Anything else we need to know?: I thought it might related to api version, and then I switch to EKS 1.26 cluster. The apiversion in the default config file is kubelet.config.k8s.io/v1beta1 and credentialprovider.kubelet.k8s.io/v1beta1, and when I tested with a pod with ECR image, the result is identical. node image: ami-028547407941241ec

maximmold commented 1 year ago

I'm seeing the same thing. Everything seems to be pulling fine despite the errors.

cartermckinnon commented 1 year ago

The kubelet had an in-tree ECR credential provider that was removed in 1.27. On previous Kubernetes versions, issues with the external credential provider do not result in failures, because the in-tree provider will be used as a fallback (but you'll see these warnings in the logs).

We've fixed a configuration issue with the external credential provider that will be included in the next AMI release (#1269). This will make the warnings go away.

cartermckinnon commented 1 year ago

However, before 1.27 launches; we do need to ensure that the external credential provider properly matches ECR patterns for China regions; thanks for pointing our that issue @czhczh0123 .

czhczh0123 commented 1 year ago

Hi, @cartermckinnon ,

Thank you for your response. Sorry I didn't reply in time.

But I am still confused of this message. Refreshing cache for provider: *credentialprovider.defaultDockerConfigProvider

With in-tree ECR credential provider, kubelet will not auto-refresh the ECR token, right? Because I can only view the GetAuthorizationToken API once via CloudTrail when I launched a pod with my ECR image. After 12 hours, I did not see another GetAuthorizationToken API unless I pull another image for my repo.

Besides, I would like to ask whether kubelet will help refresh the token when we enable external credential provider in 1.27.

Thanks a lot.

cartermckinnon commented 1 year ago

Kubelet will only refresh credentials if it needs to -- i.e. you actually pull an image that matches the credential provider's patterns. If you're not pulling images, it's not going to refresh the tokens.