Azure Container Registry'den Azure Kubernetes Service kümesine görüntü çekileme
Not
Bu makale yardımcı oldu mu? Girdileriniz bizim için önemlidir. Bu makalenin sizin için ne kadar iyi çalıştığını veya nasıl geliştirebileceğimizi bize bildirmek için lütfen bu sayfadaki Geri Bildirim düğmesini kullanın.
Microsoft Azure Container Registry'yi Azure Kubernetes Service (AKS) ile birlikte kullanırken bir kimlik doğrulama mekanizması oluşturulmalıdır. Birkaç basit Azure CLI veya Azure PowerShell komutu kullanarak AKS ile Container Registry tümleştirmesini ayarlayabilirsiniz. Bu tümleştirme, aks kümesiyle ilişkili kubelet kimliğine bir kapsayıcı kayıt defterinden görüntü çekmek için AcrPull rolünü atar.
Bazı durumlarda, kapsayıcı kayıt defterinden AKS kümesine görüntü çekme denemesi başarısız olur. Bu makalede, kapsayıcı kayıt defterinden AKS kümesine görüntü çekerken karşılaştığınız en yaygın hataları gidermeye yönelik yönergeler sağlanır.
Başlamadan önce
Bu makalede, var olan bir AKS kümeniz ve var olan bir kapsayıcı kayıt defteriniz olduğu varsayılır. Aşağıdaki hızlı başlangıçlara bakın:
AKS kümesine ihtiyacınız varsa Azure CLI veya Azure portalını kullanarak bir küme dağıtın.
Azure Container Registry 'ye (ACR) ihtiyacınız varsa, Azure CLI'yi veya Azure portalını kullanarak bir tane oluşturun.
Ayrıca Azure CLI sürüm 2.0.59 veya sonraki bir sürümün yüklenip yapılandırılması gerekir. Sürümü belirlemek için az version komutunu çalıştırın. Yüklemeniz veya yükseltmeniz gerekiyorsa bkz . Azure CLI'yı yükleme.
Belirtiler ve ilk sorun giderme
Kubernetes podunun STATUS değeri ImagePullBackOff veya ErrImagePull şeklindedir. Ayrıntılı hata bilgilerini almak için aşağıdaki komutu çalıştırın ve çıkıştan Olaylar'ı denetleyin.
kubectl describe pod <podname> -n <namespace>
Kapsayıcı kayıt defterinin durumunu denetleyerek ve kapsayıcı kayıt defterinin AKS kümesinden erişilebilir olup olmadığını denetleyerek sorun gidermeye başlamanızı öneririz.
Kapsayıcı kayıt defterinin durumunu denetlemek için aşağıdaki komutu çalıştırın:
az acr check-health --name <myregistry> --ignore-errors --yes
Bir sorun algılanırsa, bir hata kodu ve açıklama sağlar. Hatalar ve olası çözümler hakkında daha fazla bilgi için bkz . Sistem durumu denetimi hata başvurusu.
Not
Helm ile ilgili veya Noter ile ilgili hatalar alıyorsanız, bu bir sorunun Container Registry veya AKS'yi etkilediği anlamına gelmez. Yalnızca Helm veya Noter'in yüklü olmadığını ya da Azure CLI'nin Helm veya Noter'in geçerli yüklü sürümüyle uyumlu olmadığını vb. gösterir.
Kapsayıcı kayıt defterinin AKS kümesinden erişilebilir olup olmadığını doğrulamak için aşağıdaki az aks check-acr komutunu çalıştırın:
az aks check-acr --resource-group <MyResourceGroup> --name <MyManagedCluster> --acr <myacr>.azurecr.io
Aşağıdaki bölümler, komutun çıkışındaki kubectl describe pod
Olaylar bölümünde görüntülenen en yaygın hataları gidermenize yardımcı olur.
Neden 1: 401 Yetkisiz hata
AKS kümesi bir kimlik gerektirir. Bu kimlik yönetilen kimlik veya hizmet sorumlusu olabilir. AKS kümesi yönetilen kimlik kullanıyorsa, kubelet kimliği ACR ile kimlik doğrulaması için kullanılır. AKS kümesi hizmet sorumlusu kimliği olarak kullanıyorsa, hizmet sorumlusunun kendisi ACR ile kimlik doğrulaması için kullanılır. Kimlik ne olursa olsun, kapsayıcı kayıt defterinden görüntü çekmek için kullanılan uygun yetkilendirme gereklidir. Aksi takdirde, aşağıdaki "401 Yetkisiz" hatasını alabilirsiniz:
"<acrname.azurecr.io/>< repository:tag>" görüntüsü çekilemedi: [rpc hatası: kod = Bilinmeyen desc = "<acrname.azurecr.io/ repository:tag": "<acrname.azurecr.io/>><< repository:tag>>" başvurusu çözümlenemedi: yetkilendirilemedi: oauth belirtecini getiremedi: beklenmeyen durum: 401 Yetkisiz
Aşağıdaki kısıtlamalara bağlı olarak çeşitli çözümler bu hatayı çözmenize yardımcı olabilir:
2, 3 ve 5 çözümleri yalnızca hizmet sorumlusu kullanan AKS kümeleri için geçerlidir.
1, 2, 3 ve 4 çözümleri, AKS kimliği için Container Registry düzeyinde rol ataması oluşturmanın Azure yöntemi için geçerlidir.
Çözüm 5 ve 6, Kubernetes gizli dizisini çekmek için Kubernetes yöntemi için geçerlidir.
Çözüm 1: Kimlik için AcrPull rol ataması oluşturulduğuna emin olun
AKS ile Container Registry arasındaki tümleştirme, AKS kümesinin kubelet kimliği için kapsayıcı kayıt defteri düzeyinde bir AcrPull rol ataması oluşturur. Rol atamasının oluşturulduğundan emin olun.
AcrPull rol atamasının oluşturulup oluşturulmadığını denetlemek için aşağıdaki yöntemlerden birini kullanın:
Şu komutu çalıştırın:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table
Azure Container Registry>Access denetimi (IAM)>Rol atamaları'nı seçerek Azure portalını denetleyin. Daha fazla bilgi için bkz . Azure portalını kullanarak Azure rol atamalarını listeleme.
AcrPull rolünün yanı sıra, bazı yerleşik roller ve özel roller de "Microsoft.ContainerRegistry/registries/pull/read" eylemini içerebilir. Varsa bu rolleri denetleyin.
AcrPull rol ataması oluşturulmadıysa, aşağıdaki komutla AKS kümesi için Container Registry tümleştirmesini yapılandırarak oluşturun:
az aks update -n <myAKSCluster> -g <myResourceGroup> --attach-acr <acr-resource-id>
Çözüm 2: Hizmet sorumlusu süresinin dolmadığından emin olun
AKS kümesiyle ilişkili hizmet sorumlusunun gizli dizisinin süresinin dolmadığından emin olun. Hizmet sorumlunuzun son kullanma tarihini denetlemek için aşağıdaki komutları çalıştırın:
SP_ID=$(az aks show --resource-group <myResourceGroup> --name <myAKSCluster> \
--query servicePrincipalProfile.clientId -o tsv)
az ad app credential list --id "SP_ID" --query "[].endDateTime" --output tsv
Daha fazla bilgi için bkz . Hizmet sorumlunuzun son kullanma tarihini denetleme.
Gizli dizinin süresi dolduysa AKS kümesinin kimlik bilgilerini güncelleştirin.
Çözüm 3: Doğru hizmet sorumlusuna AcrPull rolünün atandığından emin olun
Bazı durumlarda kapsayıcı kayıt defteri rol ataması yine de eski hizmet sorumlusuna başvurur. Örneğin AKS kümesinin hizmet sorumlusu yenisiyle değiştirildiğinde. Kapsayıcı kayıt defteri rol atamasının doğru hizmet sorumlusuna başvurduğundan emin olmak için şu adımları izleyin:
AKS kümesi tarafından kullanılan hizmet sorumlusunu denetlemek için aşağıdaki komutu çalıştırın:
az aks show --resource-group <myResourceGroup> \ --name <myAKSCluster> \ --query servicePrincipalProfile.clientId \ --output tsv
Kapsayıcı kayıt defteri rol ataması tarafından başvuruda bulunan hizmet sorumlusunu denetlemek için aşağıdaki komutu çalıştırın:
az role assignment list --scope /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.ContainerRegistry/registries/<acrname> -o table
İki hizmet sorumlusunu karşılaştırın. Eşleşmiyorsa AKS kümesini kapsayıcı kayıt defteriyle yeniden tümleştirin.
Çözüm 4: AKS VMSS'de kubelet kimliğine başvuruldığından emin olun
Yönetilen kimlik, ACR ile kimlik doğrulaması için kullanıldığında, yönetilen kimlik kubelet kimliği olarak bilinir. Varsayılan olarak, kubelet kimliği AKS VMSS düzeyinde atanır. Kubelet kimliği AKS VMSS'den kaldırılırsa AKS düğümleri ACR'den görüntü çekemez.
AKS kümenizin kubelet kimliğini bulmak için aşağıdaki komutu çalıştırın:
az aks show --resource-group <MyResourceGroup> --name <MyManagedCluster> --query identityProfile.kubeletidentity
Ardından düğüm kaynak grubundan VMSS'yi açıp Azure portalında atanan Kimlik>Kullanıcısı'nı seçerek veya aşağıdaki komutu çalıştırarak AKS VMSS'nin kimliklerini listeleyebilirsiniz:
az vmss identity show --resource-group <NodeResourceGroup> --name <AksVmssName>
AKS kümenizin kubelet kimliği AKS VMSS'ye atanmamışsa yeniden atayın.
Not
IaaS API'lerini kullanarak veya Azure portalından AKS VMSS'yi değiştirmek desteklenmez ve aks işlemi AKS VMSS'den kubelet kimliğini kaldıramaz. Bu, beklenmeyen bir şeyin bunu kaldırdığı anlamına gelir; örneğin, bir ekip üyesi tarafından gerçekleştirilen el ile kaldırma. Bu tür bir kaldırma veya değişikliği önlemek için NRGLockdown özelliğini kullanmayı düşünebilirsiniz.
AKS VMSS'de yapılan değişiklikler desteklenmediğinden AKS düzeyinde yayılmaz. Kubelet kimliğini AKS VMSS'ye yeniden atamak için bir mutabakat işlemi gerekir. Bunu yapmak için aşağıdaki komutu çalıştırın:
az aks update --resource-group <MyResourceGroup> --name <MyManagedCluster>
Çözüm 5: Hizmet sorumlusunun doğru olduğundan ve gizli dizinin geçerli olduğundan emin olun
Görüntü çekme gizli dizisi kullanarak bir görüntü çekerseniz ve Kubernetes gizli dizisi bir hizmet sorumlusunun değerleri kullanılarak oluşturulduysa, ilişkili hizmet sorumlusunun doğru olduğundan ve gizli dizinin hala geçerli olduğundan emin olun. Şu adımları izleyin:
Kubernetes gizli dizisinin değerlerini görmek için aşağıdaki kubectl get ve base64 komutunu çalıştırın:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
Aşağıdaki az ad sp credential list komutunu çalıştırarak sona erme tarihini denetleyin. Kullanıcı adı hizmet sorumlusu değeridir.
az ad sp credential list --id "<username>" --query "[].endDate" --output tsv
Gerekirse aşağıdaki az ad sp credential reset komutunu çalıştırarak bu hizmet sorumlusunun gizli dizisini sıfırlayın :
az ad sp credential reset --name "$SP_ID" --query password --output tsv
Kubernetes gizli dizisini uygun şekilde güncelleştirin veya yeniden oluşturun.
Çözüm 6: Kubernetes gizli dizisinin kapsayıcı kayıt defteri yönetici hesabının doğru değerlerine sahip olduğundan emin olun
Görüntü çekme gizli dizisi kullanarak bir görüntü çekerseniz ve Kubernetes gizli dizisi kapsayıcı kayıt defteri yönetici hesabının değerleri kullanılarak oluşturulduysa, Kubernetes gizli dizisindeki değerlerin kapsayıcı kayıt defteri yönetici hesabının değerleriyle aynı olduğundan emin olun. Şu adımları izleyin:
Kubernetes gizli dizisinin değerlerini görmek için aşağıdaki kubectl get ve base64 komutunu çalıştırın:
kubectl get secret <secret-name> --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
Azure portalında Kapsayıcı kayıt defterleri'ni arayın ve seçin.
Kapsayıcı kayıt defterleri listesinde kapsayıcı kayıt defterinizi seçin.
Kapsayıcı kayıt defterinin gezinti bölmesinde Erişim anahtarları'nı seçin.
Kapsayıcı kayıt defterinin Erişim anahtarları sayfasında kapsayıcı kayıt defteri değerlerini Kubernetes gizli dizisindeki değerlerle karşılaştırın.
Değerler eşleşmiyorsa Kubernetes gizli dizisini uygun şekilde güncelleştirin veya yeniden oluşturun.
Not
Parolayı yeniden oluştur işlemi oluştuysa, kapsayıcı kayıt defterinin Etkinlik günlüğü sayfasında "Kapsayıcı Kayıt Defteri Oturum Açma Kimlik Bilgilerini Yeniden Oluştur" adlı bir işlem görüntülenir. Etkinlik günlüğünde 90 günlük saklama süresi vardır.
Neden 2: Görüntü bulunamadı hatası
"<acrname.azurecr.io/<> repository:tag>" görüntüsü çekilemedi: [rpc hatası: kod = NotFound desc = "<acrname.azurecr.io/ repository:tag>" görüntüsünü çekemedi ve paketten çıkaramadı: "<acrname.azurecr.io/<<> repository:tag>": <acrname.azurecr.io/>>< repository:tag>: bulunamadı
Çözüm: Görüntü adının doğru olduğundan emin olun
Bu hatayı görürseniz, görüntü adının tamamen doğru olduğundan emin olun. Kayıt defteri adını, kayıt defteri oturum açma sunucusunu, depo adını ve etiketini denetlemeniz gerekir. Yaygın bir hata, oturum açma sunucusunun "azurecr.io" yerine "azureacr.io" olarak belirtiliyor olmasıdır.
Görüntü adı tam olarak doğru değilse, AKS kapsayıcı kayıt defterinin anonim çekme erişimini etkinleştirip etkinleştirmediğinden bağımsız olarak her zaman anonim çekmeyi denediğinden 401 Yetkisiz hatası da oluşabilir.
Neden 3: 403 Yasak hatası
"<acrname.azurecr.io/<> repository:tag>" görüntüsü çekilemedi: rpc hatası: kod = Bilinmeyen desc = "<acrname.azurecr.io/ repository:tag": "<acrname.azurecr.io/>><< repository:tag>>" başvurusu çözümlenemedi: yetkilenemedi: anonim belirteci getiremedi: beklenmeyen durum: 403 Yasak
Çözüm 1: AKS sanal ağ bağlantısının kapsayıcı kayıt defterinin Özel DNS bölgesinde ayarlandığından emin olun
Kapsayıcı kayıt defterinin özel uç noktasının ve AKS kümesinin ağ arabirimi farklı sanal ağlardaysa, AKS kümesinin sanal ağı için sanal ağ bağlantısının kapsayıcı kayıt defterinin Özel DNS bölgesinde ayarlandığından emin olun. (Bu bağlantı varsayılan olarak "privatelink.azurecr.io" olarak adlandırılır.) Sanal ağ bağlantısı kapsayıcı kayıt defterinin Özel DNS bölgesinde değilse, aşağıdaki yollardan birini kullanarak ekleyin:
Azure portalında özel DNS bölgesini "privatelink.azurecr.io" seçin, Ayarlar panelinin altında Sanal ağ bağlantıları>Ekle'yi seçin ve ardından AKS kümesinin bir adını ve sanal ağını seçin. Tamam'ı seçin.
Not
"Otomatik kaydı etkinleştir" özelliğini seçmek isteğe bağlıdır.
Azure CLI kullanarak belirtilen Özel DNS bölgesine bir sanal ağ bağlantısı oluşturun.
Çözüm 2: KAPSAYıCı kayıt defterinin izin verilen IP adresi aralığına AKS Load Balancer'ın genel IP adresini ekleme
AKS kümesi kapsayıcı kayıt defterine genel olarak bağlanıyorsa (özel bağlantı veya uç nokta üzerinden DEĞİl) ve kapsayıcı kayıt defterinin genel ağ erişimi seçili ağlarla sınırlıysa, AKS Load Balancer'ın genel IP adresini kapsayıcı kayıt defterinin izin verilen IP adresi aralığına ekleyin:
Genel ağ erişiminin seçili ağlara sınırlı olduğunu doğrulayın.
Azure portalında kapsayıcı kayıt defterine gidin. Ayarlar'ın altında Ağ İletişimi’ni seçin. Genel erişim sekmesinde, Genel ağ erişimi Seçili ağlar veya Devre Dışı olarak ayarlanır.
Aşağıdaki yollardan birini kullanarak AKS Load Balancer'ın genel IP adresini alın:
Azure portalında AKS kümesine gidin. Ayarlar'ın altında Özellikler'i seçin, altyapı kaynak grubundaki sanal makine ölçek kümelerinden birini seçin ve AKS Load Balancer'ın genel IP adresini denetleyin.
Şu komutu çalıştırın:
az network public-ip show --resource-group <infrastructure-resource-group> --name <public-IP-name> --query ipAddress -o tsv
Aşağıdaki yollardan birini kullanarak AKS Load Balancer'ın genel IP adresinden erişime izin verin:
Komutunu aşağıdaki gibi çalıştırın
az acr network-rule add
:az acr network-rule add --name acrname --ip-address <AKS-load-balancer-public-IP-address>
Daha fazla bilgi için bkz . Kayıt defterine ağ kuralı ekleme.
Azure portalında kapsayıcı kayıt defterine gidin. Ayarlar'ın altında Ağ İletişimi’ni seçin. Genel erişim sekmesindeki Güvenlik Duvarı'nın altında AKS Load Balancer'ın genel IP adresini Adres aralığına ekleyin ve kaydet'i seçin. Daha fazla bilgi için bkz . Seçili genel ağdan erişim - portal.
Not
Genel ağ erişimi Devre Dışı olarak ayarlandıysa, önce Seçili ağlar'a geçin.
Neden 4: "G/Ç zaman aşımı hatası"
"<acrname.azurecr.io/>< repository:tag>" görüntüsü çekilemedi: rpc hatası: kod = Bilinmeyen desc = "<acrname.azurecr.io/>< repository:tag>" görüntüsünü çekemedi ve açamadı: "<acrname.azurecr.io/> azurecr.io/< başvurusu çözümlenemedirepository:tag>": istek yapılamadı: Head "https://< acrname.azurecr.io/v2/<> repository>/manifests/v1": dial tcp <acrprivateipaddress>:443: g/ç zaman aşımı
Not
"G/Ç zaman aşımı" hatası yalnızca Azure Özel Bağlantı kullanarak bir kapsayıcı kayıt defterine özel olarak bağlandığınızda oluşur.
Çözüm 1: Sanal ağ eşlemenin kullanıldığından emin olun
Kapsayıcı kayıt defterinin özel uç noktasının ve AKS kümesinin ağ arabirimi farklı sanal ağlardaysa, sanal ağ eşlemesinin her iki sanal ağ için de kullanıldığından emin olun. Sanal ağ eşlemesini denetlemek için Azure CLI komutunu az network vnet peering list --resource-group <MyResourceGroup> --vnet-name <MyVirtualNetwork> --output table
çalıştırabilir veya Azure portalında Ayarlar panelinin altındaki VNETs>Eşlemeleri'ni seçebilirsiniz. Belirtilen bir sanal ağın tüm eşlemelerini listeleme hakkında daha fazla bilgi için bkz . az network vnet peering list.
Sanal ağ eşlemesi her iki sanal ağ için de kullanılıyorsa, durumun "Bağlı" olduğundan emin olun. Durum Bağlantısı Kesildi ise, eşlemeyi her iki sanal ağdan da silin ve yeniden oluşturun. Durum "Bağlı" ise sorun giderme kılavuzuna bakın: Eşleme durumu "Bağlandı".
Daha fazla sorun giderme için AKS düğümlerinden veya podlarından birine bağlanın ve ardından Telnet veya Netcat yardımcı programını kullanarak kapsayıcı kayıt defteriyle bağlantıyı TCP düzeyinde test edin. komutuyla nslookup <acrname>.azurecr.io
IP adresini denetleyin ve komutunu çalıştırın telnet <ip-address-of-the-container-registry> 443
.
AKS düğümlerine bağlanma hakkında daha fazla bilgi için bakım veya sorun giderme için bkz. SSH ile Azure Kubernetes Service (AKS) küme düğümlerine bağlanma.
Çözüm 2: Azure Güvenlik Duvarı Hizmeti kullanma
Kapsayıcı kayıt defterinin özel uç noktasının ve AKS kümesinin ağ arabirimi, sanal ağ eşlemesine ek olarak farklı sanal ağlardaysa, Azure'da merkez-uç ağ topolojisi ayarlamak için Azure Güvenlik Duvarı Hizmeti'ni kullanabilirsiniz. Güvenlik duvarı kuralını ayarlarken, kapsayıcı kayıt defteri özel uç nokta IP adreslerine giden bağlantıya açıkça izin vermek için ağ kurallarını kullanmanız gerekir.
Neden 5: Bildirimde platform için eşleşme yok
Konak işletim sistemi (düğüm işletim sistemi), pod veya kapsayıcı için kullanılan görüntüyle uyumlu değil. Örneğin, bir Windows düğümünde Linux kapsayıcısı veya Linux düğümünde bir Windows kapsayıcısı çalıştırmak için bir pod zamanlarsanız aşağıdaki hata oluşur:
"<acrname.azurecr.io/>< repository:tag>" görüntüsü çekilemedi:
[
rpc hatası:
code = NotFound
desc = "<acrname.azurecr.io/>< repository:tag>" görüntüsünü çekemedi ve paketten çıkaramadı: bildirimde platform için eşleşme yok: bulunamadı,
]
Bu hata, görüntü konak işletim sistemiyle uyumsuz olduğu sürece herhangi bir kaynaktan çekilen bir görüntü için oluşabilir. Hata, kapsayıcı kayıt defterinden çekilen görüntülerle sınırlı değildir.
Çözüm: Podunuzda veya dağıtımınızda nodeSelector alanını doğru yapılandırma
Podunuzun veya dağıtımınızın yapılandırma ayarlarında doğru nodeSelector
alanı belirtin. Bu alanın kubernetes.io/os
ayarı için doğru değer, podun doğru düğüm türünde zamanlanmasını sağlar. Aşağıdaki tabloda YAML'de ayarın kubernetes.io/os
nasıl ayarlanacağı gösterilmektedir:
Konteyner türü | YAML ayarı |
---|---|
Linux kapsayıcısı | "kubernetes.io/os": linux |
Windows kapsayıcısı | "kubernetes.io/os": windows |
Örneğin, aşağıdaki YAML kodu bir Linux düğümünde zamanlanması gereken bir podu açıklar:
apiVersion: v1
kind: Pod
metadata:
name: aspnetapp
labels:
app: aspnetapp
spec:
containers:
- image: "mcr.microsoft.com/dotnet/core/samples:aspnetapp"
name: aspnetapp-image
ports:
- containerPort: 80
protocol: TCP
nodeSelector:
"kubernetes.io/os": linux
Daha Fazla Bilgi
Bu makaledeki sorun giderme kılavuzu sorunu çözmenize yardımcı olmazsa, göz önünde bulundurmanız gereken diğer bazı şeyler şunlardır:
Bu öğelerden herhangi birine sahipseniz alt ağlarla ilişkili ağ güvenlik gruplarını ve yönlendirme tablolarını denetleyin.
Güvenlik duvarı gibi bir sanal gereç alt ağlar arasındaki trafiği denetlerse güvenlik duvarını ve Güvenlik duvarı erişim kurallarını denetleyin.
Üçüncü taraf bilgileri hakkında yasal uyarı
Bu makalede adı geçen üçüncü taraf ürünleri Microsoft'tan bağımsız şirketler tarafından üretilmektedir. Microsoft, bu ürünlerin performansı veya güvenilirliği ile ilgili örtük veya başka türlü hiçbir garanti vermez.
Yardım için bize ulaşın
Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.