Deseo implementar un servicio dockerizado con kubernetes en aws. Para hacerlo, estoy usando la función AWS EKS con AWS Fargate lanzada recientemente. La imagen de la ventana acoplable del servicio se almacena en un paquete privado en github.
Para implementar mi servicio, estoy usando un archivo de manifiesto de Kubernetes que contiene un secreto, una implementación y un servicio.
Cuando se implementa localmente con kubectl en minikube, los pods de implementación extraen correctamente la imagen del paquete privado de github. Reproduje con éxito el proceso para acceder a un registro dockerhub privado.
Luego configuré kubectl para conectarme a mi clúster eks. Al aplicar el archivo de manifiesto, obtengo un estado de ImagePullBackOff para los pods de implementación cuando extraigo paquetes de github mientras funciona bien cuando extraigo de dockerhub . Las diferencias en el archivo de manifiesto son las siguientes:
Generando secreto para paquetes de github:
kubectl create secret docker-registry mySecret --dry-run=true --docker-server=https://docker.pkg.github.com --docker-username=myGithubUsername --docker-password=myGithubAccessToken -o yamlGenerando secreto para dockerhub:
kubectl create secret docker-registry mySecret --dry-run=true --docker-server=https://index.docker.io/v1/ --docker-username=myDockerhubUsername --docker-password=myDockerhubPassword -o yamlSe hace referencia a la especificación de implementación de la siguiente manera:
spec: containers: # when pulling from github packages - image: docker.pkg.github.com/myGithubUsername/myRepo/myPackage:tag # when pulling from dockerhub - image: myDockerhubUsername/repository:tag ... imagePullSecrets: - name: mySecretTratando de hacer que esto funcione específicamente con los paquetes de github, probé con AWS Secrets Manager.
Creé un secreto "mySecret" de la siguiente manera:
{ "username" : "myGithubUsername", "password" : "myGithubAccessToken" }Luego creé una política para acceder a este secreto:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:eu-west-1:myAWSAccountId:secret:mySecret" ] } ] }Luego adjunté la política tanto al rol de IAM del clúster de mi clúster eks como al rol de ejecución del pod al que se hace referencia en su perfil de fargate "fp-default". Solo estoy trabajando en el espacio de nombres predeterminado de kubernetes. Mi secreto y mi grupo están en la región eu-west-1.
Aún así, obtengo el estado de ImagePullBackOff al implementar.
Me está costando encontrar algo que aborde este problema con AWS Fargate con AWS EKS, y me encantaría saber más sobre esto :)
Editar : la pregunta se editó para presentar de una manera más clara que el problema está relacionado principalmente con el uso de paquetes de github como proveedor de registro.
Creo que necesita crear su secreto en el mismo espacio de nombres que su implementación. Pude conseguir este trabajo creando un secreto
kubectl create secret docker-registry mySecret --dry-run=true --docker-server=https://docker.pkg.github.com --docker-username=myGithubUsername --docker-password=myGithubAccessToken --namespace=my-api -o yamlen mi deployment.yaml, lo mencioné como
spec: containers: - name: my-api image: docker.pkg.github.com/doc-api:0.0.0 ports: - containerPort: 5000 resources: {} imagePullSecrets: - name: mySecretDespués de investigar un poco e intercambiar con parte del personal técnico de AWS:
El problema parece ser que EKS Fargate usa Containerd debajo del capó.
Containerd y Docker intentan extraer imágenes de manera diferente. Containerd actualmente está rastreando múltiples problemas con múltiples proveedores de registro que solo admiten correctamente Docker pero no OCI HTTP API V2, siendo github uno de ellos .
Como mencionó el director de producto de Github, el problema se abordará en unas pocas semanas o un par de meses.
Si no hay esperanza con los documentos de AWS, puede hacer lo siguiente:
Estos pods tienen un cliente docker y ejecutan el siguiente "comando"
docker login docker.pkg.github.com -u username -p passWord Ahora inicia sesión dentro del contenedor, pero no se refleja en el archivo Node. luego, necesita montar otro volumen hostPath ( ~/.docker/config.json ). Pero el desafío es saber cuál es el directorio de inicio de Fargate Nodes. En el ejemplo a continuación, puse /root (volúmenes), pero puede ser otra cosa, por ejemplo, /home/ec2-user ... algo para verificar.
Así es como esto luce
apiVersion: apps/v1 kind: Daemonset metadata: name: docker-init spec: replicas: 1 template: metadata: name: worker labels: app: worker spec: initContainers: - name: login-private-registies image: docker command: ['sh', '-c', 'docker login docker.pkg.github.com -u username -p passWord'] volumeMounts: - name: dockersock mountPath: "/var/run/docker.sock" - name: dockerconfig mountPath: "/root/.docker" volumes: - name: dockersock hostPath: path: /var/run/docker.sock - name: dockerconfig hostPath: path: /root/.docker