Azure Kubernetes Service'te (AKS) kubenet ağını kendi IP adresi aralıklarınızla kullanma

AKS kümeleri kubenet kullanır ve varsayılan olarak sizin için bir Azure sanal ağı ve alt ağı oluşturur. Kubenet ile düğümler, Azure sanal ağın alt ağından IP adresi alır. Podlar, düğümlerin Azure sanal ağ alt ağından mantıksal olarak farklı olan bir adres alanından IP adresi alır. Daha sonra podların Azure sanal ağındaki kaynaklara ulaşabilmesi için ağ adresi çevirisi (NAT) yapılandırılır. Trafiğin kaynak IP adresi, düğümün birincil IP adresine NAT'dır. Bu yaklaşım, podların kullanması için ağ alanınızda ayırmanız gereken IP adreslerinin sayısını büyük ölçüde azaltır.

Azure Container Networking Interface (CNI) ile her pod alt ağdan bir IP adresi alır ve doğrudan erişilebilir. Bu IP adresleri önceden planlanmalıdır ve ağ alanınız genelinde benzersiz olmalıdır. Her düğümün desteklediği en fazla pod sayısı için bir yapılandırma parametresi vardır. Düğüm başına eşdeğer IP adresi sayısı daha sonra bu düğüm için önceden ayrılır. Bu yaklaşım daha fazla planlama gerektirir ve genellikle IP adresi tükenmesine veya uygulamanızın talebi arttıkça daha büyük bir alt ağda kümeleri yeniden oluşturma gereksinimine yol açar. Küme oluşturma zamanında veya yeni düğüm havuzları oluştururken düğüme dağıtılabilen en fazla pod sayısını yapılandırabilirsiniz. Yeni düğüm havuzları oluştururken belirtmezseniz maxPods kubenet için varsayılan 110 değerini alırsınız.

Bu makalede, aks kümesi için sanal ağ alt ağı oluşturmak ve kullanmak için kubenet ağının nasıl kullanılacağı gösterilmektedir. Ağ seçenekleri ve dikkat edilmesi gerekenler hakkında daha fazla bilgi için bkz . Kubernetes ve AKS için ağ kavramları.

Önkoşullar

• AKS kümesinin sanal ağı giden İnternet bağlantısına izin vermelidir.
• Aynı alt ağda birden fazla AKS kümesi oluşturmayın.
• AKS kümeleri Kubernetes hizmet adres aralığı, pod adres aralığı veya 192.0.2.0/24 küme sanal ağ adres aralığı için , 172.31.0.0/16172.30.0.0/16, veya kullanamaz169.254.0.0/16. Kümenizi oluşturduktan sonra aralık güncelleştirilemez.
• AKS kümesi tarafından kullanılan küme kimliği en azından sanal ağınızdaki alt ağda Ağ Katkıda Bulunanı rolüne sahip olmalıdır. CLI, rol atamasının otomatik olarak ayarlanmasına yardımcı olur. ARM şablonu veya başka istemciler kullanıyorsanız rol atamasını el ile ayarlamanız gerekir. Küme kimliği oluşturmak ve izin atamak için abonelik sahibi gibi uygun izinlere de sahip olmanız gerekir. Yerleşik Ağ Katkıda Bulunanı rolünü kullanmak yerine özel bir rol tanımlamak istiyorsanız aşağıdaki izinlere ihtiyacınız vardır:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Uyarı

Windows Server düğüm havuzlarını kullanmak için Azure CNI kullanmanız gerekir. Kubenet ağ modeli Windows Server kapsayıcılarında kullanılamaz.

Başlamadan önce

Azure CLI sürüm 2.0.65 veya üzerinin yüklü ve yapılandırılmış olması gerekir. Sürümü bulmak için az --version komutunu çalıştırın. Yüklemeniz veya yükseltmeniz gerekirse, bkz. Azure CLI yükleme.

Kendi alt ağınızla kubenet ağına genel bakış

Birçok ortamda, ayrılmış IP adresi aralıklarına sahip sanal ağlar ve alt ağlar tanımlamış ve bu kaynakları birden çok hizmet ve uygulamayı desteklemek için kullanırsınız. AKS kümeleri, ağ bağlantısı sağlamak için kubenet (temel ağ) veya Azure CNI (gelişmiş ağ) kullanabilir.

kubenet ile sanal ağ alt ağında yalnızca düğümler bir IP adresi alır. Podlar birbirleriyle doğrudan iletişim kuramaz. Bunun yerine, Kullanıcı Tanımlı Yönlendirme (UDR) ve IP iletme düğümler arasında podlar arasındaki bağlantıyı işler. UDR'ler ve IP iletme yapılandırması AKS hizmeti tarafından varsayılan olarak oluşturulur ve korunur, ancak isterseniz özel yol yönetimi için kendi yol tablonuzu getirebilirsiniz. Ayrıca, atanmış bir IP adresi alan ve uygulama için trafiği yük dengeleyen bir hizmetin arkasına pod dağıtabilirsiniz. Aşağıdaki diyagramda AKS düğümlerinin sanal ağ alt ağında bir IP adresini nasıl aldığı, ancak podların nasıl alamayacağı gösterilmektedir:

Azure desteği UDR'de en fazla 400 yol olduğundan 400 düğümden büyük bir AKS kümesine sahip olamazsınız. AKS sanal düğümleri ve Azure Ağ İlkeleri kubenet ile desteklenmez. Calico Ağ İlkeleri desteklenir.

Azure CNI ile her pod, IP alt akında bir IP adresi alır ve diğer podlar ve hizmetlerle doğrudan iletişim kurabilir. Kümeleriniz belirttiğiniz IP adresi aralığı kadar büyük olabilir. Ancak, IP adresi aralığını önceden planlamanız gerekir ve tüm IP adresleri, desteklenebileceği en fazla pod sayısına göre AKS düğümleri tarafından kullanılır. Sanal düğümler veya Ağ İlkeleri (Azure veya Calico) gibi gelişmiş ağ özellikleri ve senaryoları Azure CNI ile desteklenir.

Kubenet ile ilgili sınırlamalar ve dikkat edilmesi gerekenler

• Kubenet tasarımında pod iletişimine küçük gecikme süresi ekleyen ek bir atlama gereklidir.
• Kubenet kullanmak için yol tabloları ve kullanıcı tanımlı yollar gereklidir ve bu da işlemlerin karmaşıklığını artırır.
  • Daha fazla bilgi için bkz. AKS'de kullanıcı tanımlı yönlendirme tablosuyla küme çıkışını özelleştirme ve AKS'de giden türlerle küme çıkışını özelleştirme.
• Kubenet tasarımı nedeniyle kubenet için doğrudan pod adresleme desteklenmez.
• Azure CNI kümelerinden farklı olarak, birden çok kubenet kümesi bir alt ağı paylaşamaz.
• AKS, alt ağına Ağ Güvenlik Grupları (NSG) uygulamaz ve bu alt ağ ile ilişkili NSG'lerin hiçbirini değiştirmez. Kendi alt ağınızı sağlar ve bu alt ağ ile ilişkili NSG'leri eklerseniz, NSG'lerdeki güvenlik kurallarının düğüm ile pod CIDR arasında trafiğe izin vermesini sağlamanız gerekir. Daha fazla ayrıntı için bkz . Ağ güvenlik grupları.
• kubenet'te desteklenmeyen özellikler şunlardır:
  • Azure ağ ilkeleri
  • Windows düğüm havuzları
  • Sanal düğümler eklentisi

Not

Küme içindeki konnektivity gibi bazı sistem podları yer paylaşımlı adres alanından bir IP yerine konak düğümü IP adresini kullanır. Sistem podları, sanal ağdan bir IP adresi değil yalnızca düğüm IP'sini kullanır.

IP adresi kullanılabilirliği ve tükenmesi

Azure CNI ile ilgili yaygın bir sorun, atanan IP adresi aralığının kümeyi ölçeklendirdiğinizde veya yükseltirken daha fazla düğüm ekleyemeyecek kadar küçük olmasıdır. Ağ ekibi, beklenen uygulama taleplerinizi destekleyecek kadar büyük bir IP adresi aralığı da düzenleyemeyebilir.

Bir risk olarak kubenet kullanan bir AKS kümesi oluşturabilir ve mevcut bir sanal ağ alt ağına bağlanabilirsiniz. Bu yaklaşım, düğümlerin kümede çalışabilecek olası podlar için önceden çok sayıda IP adresi ayırmaya gerek kalmadan tanımlı IP adreslerini almasını sağlar. kubenet ile çok daha küçük bir IP adresi aralığı kullanabilir ve büyük kümeleri ve uygulama taleplerini destekleyebilirsiniz. Örneğin, alt ağınızda /27 IP adresi aralığıyla, ölçeklendirmek veya yükseltmek için yeterli alanı olan 20-25 düğümlü bir küme çalıştırabilirsiniz. Bu küme boyutu en fazla 2.200-2.750 pod (düğüm başına varsayılan en fazla 110 pod) destekleyebilir. AKS'de kubenet ile yapılandırabileceğiniz düğüm başına en fazla pod sayısı 250'dir.

Aşağıdaki temel hesaplamalar, ağ modellerindeki farkı karşılaştırır:

• kubenet: Basit bir /24 IP adresi aralığı, kümede en fazla 251 düğümü destekleyebilir. Her Azure sanal ağ alt ağı, yönetim işlemleri için ilk üç IP adresini ayırır. Bu düğüm sayısı, düğüm başına varsayılan en fazla 110 pod ile en fazla 27.610 pod destekler.
• Azure CNI: Aynı temel /24 alt ağ aralığı kümede yalnızca en fazla sekiz düğümü destekleyebilir. Bu düğüm sayısı, varsayılan olarak düğüm başına en fazla 30 pod ile en fazla 240 podu destekleyebilir.

Not

Bu maksimum değerler yükseltme veya ölçeklendirme işlemlerini dikkate almaz. Uygulamada, alt ağ IP adresi aralığının desteklediği en fazla düğüm sayısını çalıştıramazsınız. Ölçeklendirme veya yükseltme işlemleri için bazı IP adreslerini kullanılabilir bırakmanız gerekir.

Sanal ağ eşlemesi ve ExpressRoute bağlantıları

Şirket içi bağlantı sağlamak için hem kubenet hem de Azure-CNI ağ yaklaşımları Azure sanal ağ eşlemesini veya ExpressRoute bağlantılarını kullanabilir. Çakışmayı ve yanlış trafik yönlendirmesini önlemek için IP adresi aralıklarınızı dikkatlice planlayın. Örneğin, birçok şirket içi ağ ExpressRoute bağlantısı üzerinden tanıtılan 10.0.0.0/8 adres aralığını kullanır. AKS kümelerinizi bu adres aralığının dışındaki Azure sanal ağ alt ağlarında oluşturmanızı (örneğin , 172.16.0.0/16) öneririz.

Kullanılacak ağ modelini seçme

Aşağıdaki önemli noktalar, her ağ modelinin en uygun olduğu zamanları özetler:

Şu durumlarda kubenet kullanın:

• Ip adresi alanınız sınırlı.
• Pod iletişiminin çoğu küme içindedir.
• Sanal düğümler veya Azure Ağ İlkesi gibi gelişmiş AKS özelliklerine ihtiyacınız yoktur.

Aşağıdaki durumlarda Azure CNI kullanın:

• Kullanılabilir IP adresi alanınız var.
• Pod iletişiminin çoğu küme dışındaki kaynaklara yapılır.
• Pod bağlantısı için kullanıcı tanımlı yolları yönetmek istemezsiniz.
• Sanal düğümler veya Azure Ağ İlkesi gibi AKS gelişmiş özelliklerine ihtiyacınız vardır.

Hangi ağ modelini kullanacağınıza karar vermenize yardımcı olacak daha fazla bilgi için bkz . Ağ modellerini ve bunların destek kapsamını karşılaştırma.

Sanal ağ ve alt ağ oluşturma

1. komutunu kullanarak az group create bir kaynak grubu oluşturun.

   az group create --name myResourceGroup --location eastus
   

2. Kullanılacak bir sanal ağınız ve alt ağınız yoksa komutunu kullanarak az network vnet create bu ağ kaynaklarını oluşturun. Aşağıdaki örnek komut, adres ön eki 192.168.0.0/16 olan myAKSVnet adlı bir sanal ağ ve adres ön eki 192.168.1.0/24 olan myAKSSubnet adlı bir alt ağ oluşturur:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. komutunu kullanarak az network vnet subnet show alt ağ kaynak kimliğini alın ve daha sonra kullanmak üzere adlı SUBNET_ID bir değişken olarak depolayın.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

Sanal ağda AKS kümesi oluşturma

Sistem tarafından atanan yönetilen kimliklerle AKS kümesi oluşturma

Not

Azure CLI, sistem tarafından atanan kimliği kullanırken, küme oluşturulduktan sonra sistem tarafından atanan kimliğe Ağ Katkıda Bulunanı rolü verir. ARM şablonu veya başka istemciler kullanıyorsanız, bunun yerine kullanıcı tarafından atanan yönetilen kimliği kullanmanız gerekir.

• komutunu kullanarak az aks create sistem tarafından atanan yönetilen kimliklerle bir AKS kümesi oluşturun.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  Dağıtım parametreleri:

  • --service-cidr isteğe bağlıdır. Bu adres, AKS kümesindeki iç hizmetleri bir IP adresi atamak için kullanılır. Bu IP adresi aralığı, Express Route veya Siteden Siteye VPN bağlantısı kullanarak Azure sanal ağlarınıza bağlanırsanız veya bağlanmayı planlıyorsanız şirket içi ağ aralıkları dahil olmak üzere ağ ortamınızda başka bir yerde kullanılmamış bir adres alanı olmalıdır. Varsayılan değer 10.0.0.0/16'dır.
  • --dns-service-ip isteğe bağlıdır. Adres, hizmet IP adresi aralığınızın .10 adresi olmalıdır. Varsayılan değer 10.0.0.10'dur.
  • --pod-cidr isteğe bağlıdır. Bu adres, ağ ortamınızda başka bir yerde kullanılmamış büyük bir adres alanı olmalıdır. Bu aralık, Express Route veya Siteden Siteye VPN bağlantısı kullanarak Azure sanal ağlarınıza bağlanırsanız veya bağlanmayı planlıyorsanız tüm şirket içi ağ aralıklarını içerir. Varsayılan değer 10.244.0.0/16'dır.
    • Bu adres aralığı, ölçeği artırmayı beklediğiniz düğüm sayısını karşılayacak kadar büyük olmalıdır. Küme dağıtıldıktan sonra bu adres aralığını değiştiremezsiniz.
    • Pod IP adresi aralığı, kümedeki her düğüme / 24 adres alanı atamak için kullanılır. Aşağıdaki örnekte, 10.244.0.0/16'nın --pod-cidr değeri ilk düğüm 10.244.0.0/24,ikinci düğümü 10.244.1.0/24 ve üçüncü düğüm 10.244.2.0/24'i atar.
    • Küme ölçeklendikçe veya yükseltildikçe Azure platformu her yeni düğüme bir pod IP adresi aralığı atamaya devam eder.

Kullanıcı tarafından atanan yönetilen kimlikle AKS kümesi oluşturma

Yönetilen kimlik oluşturma

• komutunu kullanarak az identity yönetilen kimlik oluşturun. Mevcut bir yönetilen kimliğiniz varsa, bunun yerine komutunu kullanarak az identity show --ids <identity-resource-id> asıl kimliği bulun.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  Çıkışınız aşağıdaki örnek çıkışa benzemelidir:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Yönetilen kimlik için rol ataması ekleme

Azure CLI kullanıyorsanız rol otomatik olarak eklenir ve bu adımı atlayabilirsiniz. ARM şablonu veya başka istemciler kullanıyorsanız rol ataması gerçekleştirmek için küme yönetilen kimliğinin Asıl Kimliğini kullanmanız gerekir.

• komutunu kullanarak az network vnet show sanal ağ kaynak kimliğini alın ve adlı VNET_IDbir değişken olarak depolayın.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• komutunu kullanarak sanal ağda AKS kümenizin Ağ Katkıda Bulunanı izinleri için yönetilen kimliği atayın az role assignment create ve principalId> değerini <sağlayın.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Not

Azure tarafından kullanılan kümenizin yönetilen kimliğine verilen iznin doldurulma süresi 60 dakika sürebilir.

AKS kümesi oluşturma

• komutunu kullanarak az aks create bir AKS kümesi oluşturun ve kullanıcı tarafından atanan yönetilen kimliği atamak için bağımsız değişkeni için assign-identity denetim düzleminin yönetilen kimlik kaynak kimliğini sağlayın.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

AKS kümesi oluşturduğunuzda, otomatik olarak bir ağ güvenlik grubu ve yönlendirme tablosu oluşturulur. Bu ağ kaynakları AKS denetim düzlemi tarafından yönetilir. Ağ güvenlik grubu, düğümlerinizdeki sanal NIC'lerle otomatik olarak ilişkilendirilir. Yönlendirme tablosu otomatik olarak sanal ağ alt ağıyla ilişkilendirilir. Ağ güvenlik grubu kuralları ve yönlendirme tabloları, siz hizmetleri oluşturup kullanıma sunarken otomatik olarak güncelleştirilir.

Kubenet ile kendi alt ağınızı ve yönlendirme tablonuzu getirme

kubenet ile, küme alt ağlarınızda bir yönlendirme tablosu bulunmalıdır. AKS, kendi mevcut alt ağınızı ve yol tablonuzu getirmeyi destekler. Özel alt ağınız bir yönlendirme tablosu içermiyorsa AKS sizin için bir tablo oluşturur ve küme yaşam döngüsü boyunca kurallar ekler. Kümenizi oluştururken özel alt ağınız bir yönlendirme tablosu içeriyorsa AKS, küme işlemleri sırasında mevcut yol tablosunu kabul eder ve bulut sağlayıcısı işlemleri için uygun kuralları ekler/güncelleştirir.

Uyarı

Özel yol tablosuna özel kurallar ekleyebilir/güncelleştirebilirsiniz. Ancak, kubernetes bulut sağlayıcısı tarafından güncelleştirilemez veya kaldırılamaz kurallar eklenir. 0.0.0.0/0 gibi kurallar her zaman belirli bir yol tablosunda bulunmalı ve NVA veya başka bir çıkış ağ geçidi gibi İnternet ağ geçidinizin hedefiyle eşlenmelidir. Kuralları güncelleştirirken dikkatli olun.

Özel yol tablosu ayarlama hakkında daha fazla bilgi edinin.

Kubenet ağı, istekleri başarıyla yönlendirmek için düzenli yönlendirme tablosu kuralları gerektirir. Bu tasarım nedeniyle, rota tablolarının ona bağlı olan her küme için dikkatli bir şekilde korunması gerekir. Farklı kümelerden pod CIDR'leri çakışabileceğinden birden çok küme yol tablosunu paylaşamaz ve bu da beklenmeyen ve bozuk yönlendirme senaryolarına neden olabilir. Aynı sanal ağda birden çok küme yapılandırırken veya her kümeye bir sanal ağ ayırdığınızda aşağıdaki sınırlamaları göz önünde bulundurun:

• AKS kümesini oluşturmadan önce alt ağ ile özel bir yol tablosu ilişkilendirilmelidir.
• küme oluşturulduktan sonra ilişkili yol tablosu kaynağı güncelleştirilemez. Ancak, özel kurallar rota tablosunda değiştirilebilir.
• Her AKS kümesi, kümeyle ilişkili tüm alt ağlar için tek, benzersiz bir yol tablosu kullanmalıdır. Çakışan pod CIDR'leri ve çakışan yönlendirme kuralları nedeniyle bir yol tablosunu birden çok kümeyle yeniden kullanamazsınız.
• Sistem tarafından atanan yönetilen kimlik için yalnızca Azure CLI aracılığıyla kendi alt ağınızı ve yönlendirme tablonuzu sağlamanız desteklenir çünkü Azure CLI rol atamasını otomatik olarak ekler. ARM şablonu veya başka istemciler kullanıyorsanız, kullanıcı tarafından atanan bir yönetilen kimlik kullanmanız, küme oluşturmadan önce izinleri atamanız ve kullanıcı tarafından atanan kimliğin özel alt ağınız ve özel yönlendirme tablonuz için yazma izinlerine sahip olduğundan emin olmanız gerekir.
• Aynı yol tablosunun birden çok AKS kümesiyle kullanılması desteklenmez.

Not

Kubenet ağ eklentisiyle kendi sanal ağınızı ve yönlendirme tablonuzu oluşturup kullandığınızda, küme için kullanıcı tarafından atanan bir yönetilen kimlik yapılandırmanız gerekir. Sistem tarafından atanan yönetilen kimlikle, rol ataması sırasında gecikmeye neden olan bir küme oluşturmadan önce kimlik kimliğini alamazsınız.

Azure ağ eklentisiyle kendi sanal ağınızı ve yönlendirme tablonuzu oluşturup kullandığınızda hem sistem tarafından atanan hem de kullanıcı tarafından atanan yönetilen kimlikler desteklenir. KCG senaryoları için kullanıcı tarafından atanan yönetilen kimlik kullanmanızı kesinlikle öneririz.

AKS kümenize kullanıcı tarafından atanan yönetilen kimliğe sahip bir yönlendirme tablosu ekleme

Özel bir yol tablosu oluşturduktan ve bunu sanal ağınızdaki bir alt ağ ile ilişkilendirdikten sonra, kullanıcı tarafından atanan yönetilen kimlikle yol tablonuzu belirten yeni bir AKS kümesi oluşturabilirsiniz. AKS kümenizi dağıtmayı planladığınız yer için alt ağ kimliğini kullanmanız gerekir. Bu alt ağın özel yol tablonuzla da ilişkilendirilmesi gerekir.

1. komutunu kullanarak az network vnet subnet list alt ağ kimliğini alın.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. komutunu kullanarak az aks create ve parametreleri için --vnet-subnet-id --assign-identity değerlerinizi sağlayarak yönlendirme tablosuyla önceden yapılandırılmış özel bir alt ağa sahip bir AKS kümesi oluşturun.

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

Sonraki adımlar

Bu makalede AKS kümenizi mevcut sanal ağ alt ağınıza nasıl dağıtabileceğiniz gösterildi. Artık Helm kullanarak yeni uygulamalar oluşturmaya başlayabilir veya Helm'i kullanarak mevcut uygulamaları dağıtabilirsiniz.