Um den Lastausgleich, die Skalierbarkeit und die Fehlertoleranz zu gewährleisten, können zusätzliche Tools verwendet werden - Orchestratoren. Unter ihnen ist der Kubernetes-Dienst mittlerweile sehr beliebt. Der einfachste Weg, es in der Praxis zu versuchen, besteht darin, es in der Cloud bereitzustellen, was wir heute tun werden.

Hinweis: Wir setzen die Reihe der Veröffentlichungen von Vollversionen von Artikeln aus dem Hacker-Magazin fort. Rechtschreibung und Zeichensetzung des Autors gespeichert.
Erweitern Sie AKS
Wir gehen zum Azure-Portal , klicken auf "Ressource erstellen" und suchen einen Dienst namens Kubernetes Service.
Wählen Sie den Namen und das Präfix DNS nach Ihrem Geschmack. Der Name beeinflusst, wie Sie auf Ihren Cluster zugreifen, das Präfix wirkt sich jedoch auf die FQDN-Adresse aus.

Die billigste virtuelle Maschine kostet derzeit etwas mehr als 30 US-Dollar pro Monat.
Der zweite Schritt besteht darin, einen Service-Principal zu erstellen. Der Dienstprinzipal ist eine Art Dienstkonto, unter dem bestimmte Aufgaben ausgeführt werden können. Der Vorteil ist, dass die Rechte eines solchen Kontos eingeschränkt werden können. Darüber hinaus können Sie eine beliebige Anzahl solcher Konten erstellen (während die Anzahl der regulären Konten durch das Abonnement begrenzt ist). Sie finden die erstellten Dienstprinzipalkonten in Active Directory unter App-Registrierungen.

RBAC (rollenbasierte Zugriffskontrolle) ist die Fähigkeit, den Zugriff auf bestimmte Ressourcen (oder Ressourcengruppen) einzuschränken oder bereitzustellen. Das heißt, Sie können unterscheiden, welche Benutzer Ihres Abonnements Zugriffsrechte haben und welche nicht.

Im Moment dauert der Vorgang ungefähr 20 Minuten, aber alles kann von der Konfiguration abhängen.
Finden Sie offizielle Anleitungen, indem Sie den Links folgen
Erstellen Sie über das Portal einen AKS-Cluster
Erstellen eines AKS-Clusters mithilfe der CLI
Zum Arbeiten benötigen wir die Azure-Befehlszeile - CLI (Command Line Interface). Es kann sowohl unter Windows als auch unter MacOS oder Linux installiert werden. Persönlich bevorzuge ich die Azure Cloud Shell. Dies ist die Befehlszeile, die von der in den Browser geladenen Azure-Portalseite ausgeführt wird. Zum Arbeiten ist der erstellte Blob-Speicher erforderlich. Die Kosten betragen einige Cent pro Monat und deshalb mache ich mir lieber keine Gedanken über die Installation von CLI in meinem Auto.
Kubernetes unterstützt verschiedene Containertechnologien, aber schauen wir uns die beliebteste an - Docker. Mit docker.hub können Sie ein privates Docker-Image kostenlos speichern. Wenn Sie mehr brauchen, können Sie sie für Geld platzieren. Für Geld kann jedoch ein privates Docker-Image in der Azure Container-Registrierung abgelegt werden. Jetzt beginnen die Preise bei 5 USD pro Monat (für Basis-SKU).
Ich habe einen ACR-Dienst unter dem Namen myservice erstellt. Wenn Sie sich auch für die Verwendung von ACR entscheiden, müssen Sie beim Erstellen eines Dienstes dessen Schlüssel abrufen.

Dann können Sie sich anmelden, indem Sie den folgenden Befehl ausführen:
docker login myservice.azurecr.io
Geben Sie den Benutzernamen (myservice) und das Passwort aus dem Portal ein (PJSeyO9 = lCMRDI7dGkz68wjhFGRGxSY3).
Wenn Sie nun mit dem Projekt in das Verzeichnis gehen, können Sie ein Bild erstellen, während Sie es mit dem gewünschten Tag markieren. Und danach senden Sie es an den Cloud-Service:
docker build -t myservice.azurecr.io/myservice . docker push myservice.azurecr.io/myservice
Geheimnisse, Geheimnisse ... Wir bieten Zugriff auf das Bild und speichern die Einstellungen.
Wenn Sie mit bereitgestelltem AKS arbeiten, müssen Sie seine Credits erhalten. Andernfalls werden kubectl-Befehle nicht ausgeführt. Um auf AKS zuzugreifen, wird der folgende Befehl ausgeführt:
az aks get-credentials --resource-group KubernetesGroup --name verycoolcluster
Um auf das Docker-Image im Docker-Repository in einem privaten Container zugreifen zu können, müssen Sie ein Geheimnis erstellen. Wenn Sie ein öffentliches Image haben, können Sie diesen Schritt überspringen.
Um eine geheime Datei zu erstellen, müssen Sie einen Befehl der folgenden Form ausführen:
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
Befindet sich Ihr Image im Docker-Repository, lautet der Wert von <Ihr-Registrierungsserver> https://index.docker.io/v1/
Für die Azure-Containerregistrierung lautet der vollqualifizierte Domänenname <Registrierungsname> .azurecr.io
Das heißt, um in meinem Fall ein Geheimnis für den Container zu schaffen, habe ich Folgendes getan:
kubectl create secret docker-registry regcred --docker-server="myservice.azurecr.io" --docker-username="myservice" --docker-password="PJSeyO9=lCMRDI7dGkz68wjhFGRGxSY3" --docker-email="asommer@yandex.ru"
Sie können jetzt den Inhalt der erstellten geheimen Datei mit dem folgenden Befehl anzeigen:
kubectl get secret regcred --output=yaml
INFO
Wenn Sie AKS verwenden, können Sie keine geheime Datei erstellen, sondern dem AKS-Dienst auf andere Weise Zugriff auf den ACR-Dienst gewähren - indem Sie ein spezielles Skript ausführen. Sie können es von der folgenden Seite nehmen:
Authentifizieren Sie sich mit Azure Container Registry vom Azure Kubernetes Service
#!/bin/bash AKS_RESOURCE_GROUP=KubernetesGroup AKS_CLUSTER_NAME=verycoolcluster ACR_RESOURCE_GROUP=MyACRGroup ACR_NAME=myservice # Get the id of the service principal configured for AKS CLIENT_ID=$(az aks show --resource-group $AKS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query "servicePrincipalProfile.clientId" --output tsv) # Get the ACR registry resource id ACR_ID=$(az acr show --name $ACR_NAME --resource-group $ACR_RESOURCE_GROUP --query "id" --output tsv) # Create role assignment az role assignment create --assignee $CLIENT_ID --role Reader --scope $ACR_ID
Sie können einfach die Werte der Variablen AKS * und ACR * ändern, dann das Skript kopieren und in die Azure CLI oder Cloud Shell einfügen.
Kubernetes enthält einen sicheren Speicher für Anmeldeinformationen. Das heißt, Sie können eine Datei mit den Einstellungen erstellen, und der Zugriff von außen auf diese Einstellungen ist schwierig. Diese Datei enthält normalerweise Datenbankverbindungszeichenfolgen und eine Art von Credits. Wenn Sie solche Informationen nicht in der Anwendung haben (stimmt das?), Können Sie diesen Schritt überspringen.
Um eine Einstellungsdatei über die Befehlszeile zu erstellen, müssen wir zuerst den Befehl vi berücksichtigen.
vi < >
erstellt eine Datei, wenn sie fehlt oder eine vorhandene öffnet
Um die eingegebenen Änderungen zu speichern, drücken Sie ESC und dann ZZ
Um einfach zu beenden, ohne ESC zu speichern und danach: q!
Eine sehr kurze Beschreibung, aber es sollte reichen. Ich kann hinzufügen, dass der Einfügen-Schlüssel sehr nützlich sein kann.
Erstellen Sie daher über Azure Cloud Shell eine Datei mit einem beliebigen Namen (z. B. appsettings.json) und dem gewünschten Inhalt. Lassen Sie uns Folgendes zugeben:
{ "ConnectionString": "some secret string goes there" }
Und nachdem Sie den Befehl ausgeführt haben:
kubectl create secret generic secret-appsettings --from-file=/home/youraccount/appsettings.json
Dieser Befehl erstellt ein Geheimnis mit Einstellungen, die als geheime Apps bezeichnet werden
Mit dem Befehl pwd können Sie herausfinden, durch welchen Pfad / home / youraccount ersetzt werden soll
Erstellen Sie eine Bereitstellung
Bereitstellungen gelten für zustandslose Dienste. Sie beschreiben, wie Pods und ReplicaSets erstellt und wie sie aktualisiert werden. Pod ist eine Gruppe von Containern (oder ein einzelner Container), die in derselben Umgebung arbeiten. Der Zweck von ReplicaSet besteht darin, zu steuern, dass die angegebene Anzahl von Pods gestartet wird und ständig funktioniert.
Basierend auf der zuvor erstellten Datei erstelle ich eine deploy.yaml-Datei, die 3 Sub erstellt. Die Datei enthält den folgenden Code (ich erinnere Sie daran, dass Leerzeichen in yaml sehr wichtig sind):
apiVersion: apps/v1beta1 kind: Deployment metadata: name: mydeployment spec: replicas: 3 minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: myapp spec: containers: - name: app image: myservice.azurecr.io/myservice:latest ports: - containerPort: 80 name: http protocol: TCP imagePullPolicy: Always env: - name: "ASPNETCORE_ENVIRONMENT" value: "Production" volumeMounts: - name: secrets mountPath: /app/secrets readOnly: true imagePullSecrets: - name: regcred volumes: - name: secrets secret: secretName: secret-appsettings
Betrachten Sie den Code. Der Anfang beschreibt die Anzahl der Replikate und die Aktualisierungsstrategie. Anschließend erhält die Bereitstellung einen Namen (myapp) und ein Verweis auf das Container-Image wird angezeigt. Ports sind registriert. 80 ist der Standardport für http. Als Nächstes werden die ASP.NET Core-Umgebungseinstellungen aufgeführt. Dann wurden die Credits des privaten Docker-Images und die geheimen Anwendungseinstellungen, die wir kürzlich erstellt haben, bereitgestellt.
strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
Dieses Teil ist für den Upgrade-Prozess verantwortlich. maxSurge - Die Anzahl der Herde, die beim Aktualisieren über den vorhandenen Herden erstellt wurden (in Einheiten oder Prozent). maxUnavailable - Die maximale Anzahl von Herden, die während des Aktualisierungsvorgangs möglicherweise nicht mehr verfügbar sind.
Die Bereitstellung kann mit dem folgenden Befehl erstellt werden:
kubectl apply -f deploy.yaml
Treffen Sie Ingress
Um den Zugriff auf Clusterdienste bereitzustellen und den Lastenausgleich zu organisieren, wird ein Dienst namens Ingress verwendet. Eine ziemlich beliebte Lösung ist Ingress basierend auf Nginx. Der einfachste Weg, es zu installieren, ist die Verwendung des Kubernetes-Paketmanagers namens helm. Der Vorteil von Azure Cloud Shell besteht darin, dass der Helm bereits darin installiert ist. Was bleibt zu tun, um nginx-ingress zu installieren? Geben Sie ein:
helm init
Warten Sie etwas und führen Sie Folgendes aus:
helm install stable/nginx-ingress --namespace kube-system --set rbac.create=false
Erstellen von SSL-Zertifikaten mit LetsEncrypt
Da das SSL-Zertifikat an einen Domänennamen gebunden ist, legen wir unseren DNS-Ressourcennamen fest.
Führen Sie den folgenden Befehl aus und übernehmen Sie die externe IP
kubectl get service -l app=nginx-ingress --namespace kube-system
Ersetzen Sie IP und den Namen, den wir für die Subdomain im folgenden Skript erfunden haben
#!/bin/bash # Public IP address of your ingress controller IP="168.63.19.2" # Name to associate with public IP address DNSNAME="myservice-ingress" # Get the resource-id of the public ip PUBLICIPID=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[id]" --output tsv) # Update public ip address with DNS name az network public-ip update --ids $PUBLICIPID --dns-name $DNSNAME
Wir kopieren dieses Skript einfach, fügen es in die Befehlszeile ein und führen es auf diese Weise aus. Als Namen für die Subdomain habe ich einen sehr "ursprünglichen" Namen festgelegt - myservice-ingress
Installieren Sie den Zertifikatmanager auf die gleiche Weise, indem Sie das folgende Skript kopieren und in die Befehlszeile einfügen. Auch hier muss nichts Besonderes geändert werden.
helm install \ --name cert-manager \ --namespace kube-system \ stable/cert-manager \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set rbac.create=false \ --set serviceAccount.create=false
INFO
Wenn wir einen Cluster mit RBAC hätten, wäre das Skript anders.
helm install stable/cert-manager --set ingressShim.defaultIssuerName=letsencrypt-staging --set ingressShim.defaultIssuerKind=ClusterIssuer
Wenn die Zertifikatdatei verfügbar ist, können Sie sie folgendermaßen hinzufügen:
kubectl create secret tls tls-secret --cert CERT.crt --key KEY-FOR-CERT.key
Da wir jedoch kein unterschriebenes CA-Zertifikat haben, müssen wir ein wenig mit einem Tamburin tanzen. Wir werden eine Zertifizierungsstelle mit einem kostenlosen Dienst namens LetsEncrypt erstellen . LetsEncrypt ist eine Zertifizierungsstelle, die kostenlos Zertifikate ausstellt. Eine solche altruistische Organisation, deren Ziel es ist, das Internet zu sichern.
Erstellen Sie also die Datei cluster-issuer.yaml. Sie beschreibt die Organisation, die das Zertifikat ausgestellt hat.
apiVersion: certmanager.k8s.io/v1alpha1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: youeemail@yourdomain.ru privateKeySecretRef: name: letsencrypt-prod http01: {}
Sie müssen nur die E-Mail durch Ihre Adresse ersetzen und können Folgendes tun:
kubectl apply -f cluster-issuer.yaml
Anschließend erstellen wir die Zertifikatsdatei certificate.yaml, in der der Name des erstellten ClusterIssuer und die Domäne angegeben sind, für die das Zertifikat bestimmt ist - myservice-ingress.westeurope.cloudapp.azure.com
apiVersion: certmanager.k8s.io/v1alpha1 kind: Certificate metadata: name: tls-prod-secret spec: secretName: tls-prod-secret dnsNames: - myservice-ingress.westeurope.cloudapp.azure.com acme: config: - http01: ingressClass: nginx domains: - myservice-ingress.westeurope.cloudapp.azure.com issuerRef: name: letsencrypt-prod kind: ClusterIssuer
Wir führen aus:
kubectl apply -f certificate.yaml
Serviceerstellung und Ingress
Kubernetes kann vier verschiedene Arten von Diensten erstellen.
Der Standarddienst ist ClusterIP. Der Zugriff auf diesen Dienst ist nur vom Cluster über die interne IP möglich.
NodePort erstellt automatisch den ClusterIP-Dienst. Der Zugriff auf NodePort ist extern auf folgendem Weg möglich:
Der LoadBalancer Load Balancer bietet Zugriff von außen auf den Dienst und erstellt automatisch NodePort- und ClusterIP-Dienste.
ExternalName ordnet den Dienst einem externen Namen zu.
Die Grundversorgung reicht uns:
apiVersion: v1 kind: Service metadata: name: myservice spec: type: ClusterIP ports: - port: 80 name: http targetPort: http selector: app: myapp
Mit dem Wert des Selektors geben wir den Namen unserer Bereitstellung an.
Es bleibt ein Service zu erstellen
kubectl apply -f service.yaml
Und als letzten Schritt erstellen wir einen Eingang, mit dem ich Sie in diesem Artikel bereits etwas höher vorgestellt habe. In yaml geben wir den Namen des Cluster-Ausstellers und das Zertifikat an. Wir haben sie früher erstellt.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: myingress annotations: kubernetes.io/ingress.class: nginx certmanager.k8s.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/rewrite-target: / spec: tls: - hosts: - myservice-ingress.westeurope.cloudapp.azure.com secretName: tls-prod-secret rules: - host: myservice-ingress.westeurope.cloudapp.azure.com http: paths: - path: / backend: serviceName: myservice servicePort: 80
Einige Zeit nach dem Erstellen des Eingangs mit demselben Befehl kubectl apply sollte unser Microservice unter https: // myservice-ingress.westeurope.cloudapp.azure.com verfügbar sein . Durch Klicken auf das Schloss in der Adressleiste des Browsers neben https können Sie überprüfen, ob das Zertifikat gültig und von CA ausgestellt ist.

Wir erinnern Sie daran, dass dies die Vollversion eines
Artikels aus dem Hacker-Magazin ist . Sein Autor ist
Alexey Sommer .