負荷分散、スケーラビリティを確保し、フォールトトレランスを向上させるために、補助ツールであるオーケストレーターを使用できます。 その中でも、Kubernetesサービスは現在非常に人気があります。 実際に試してみる最も簡単な方法は、クラウドで展開することです。これは、今日行います。

注：Hacker誌の記事の完全版の出版物シリーズを継続します。 著者のスペルと句読点が保存されました。

AKSを展開する

Azureポータルに移動し、[リソースの作成]をクリックして、Kubernetes Serviceというサービスを見つけます。

好みに応じて名前とプレフィックスDNSを選択します。 名前はクラスターへのアクセス方法に影響しますが、プレフィックスはそのFQDNに影響します。

現在、最も安価な仮想マシンのコストは月額わずか30ドルです。

2番目のステップは、サービスプリンシパルを作成することです。 サービスプリンシパルは、特定のタスクを実行できるサービスアカウントの一種です。 利点は、そのようなアカウントの権利を制限できることです。 さらに、このようなアカウントをいくつでも作成できます（通常のアカウントの数はサブスクリプションによって制限されます）。 作成されたサービスプリンシパルアカウントは、Active Directoryのアプリ登録の中にあります。

RBAC（役割ベースのアクセス制御）は、特定のリソース（またはリソースグループ）へのアクセスを制限または提供する機能です。 つまり、サブスクリプションのどのユーザーがアクセス権を持っているか、そうでないかを区別できます。

現時点では、プロセスには約20分かかりますが、すべてが構成に依存する場合があります。

リンクをたどって公式ガイドを見つける

ポータルを使用してAKSクラスターを作成する

CLIを使用したAKSクラスターの作成

作業には、Azureコマンドライン-CLI（コマンドラインインターフェイス）が必要です。 WindowsとmacOSまたはLinuxの両方にインストールできます。 個人的には、Azure Cloud Shellを使用することを好みます。 これは、ブラウザーに読み込まれたAzureポータルページから実行されるコマンドラインです。 動作するには、作成されたblobストレージが必要です。 そのコストは月あたり数セントになるので、私は自分の車にCLIをインストールすることを心配したくない。

Kubernetesはさまざまなコンテナテクノロジーをサポートしていますが、最も人気のあるDockerを見てみましょう。 docker.hubでは、1つのプライベートdockerイメージを無料で保存できます 。 さらに必要な場合は、お金のためにそれらを配置することができます。 ただし、お金のために、プライベートDockerイメージをAzure Container Registryに配置できます。 現在、価格は月額5ドルから始まります（基本SKUの場合）。

myserviceという名前でACRサービスを作成しました。 ACRを使用することにした場合は、サービスを作成するには、そのキーを取得する必要があります。

次に、コマンドを実行してログインできるようになります。

docker login myservice.azurecr.io
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポータルから取得したユーザー名（myservice）とパスワードを入力します（PJSeyO9 = lCMRDI7dGkz68wjhFGRGxSY3）

プロジェクトのあるディレクトリに入ったら、イメージをビルドすると同時に、目的のタグでマークを付けます。 その後、クラウドサービスに送信します。

 docker build -t myservice.azurecr.io/myservice . docker push myservice.azurecr.io/myservice
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

秘密、秘密...私たちは画像へのアクセスを提供し、設定を保存します。

デプロイされたAKSを使用する場合、彼のクレジットを取得する必要があります。 そうでない場合、kubectlコマンドは実行されません。 AKSにアクセスするには、次のコマンドが実行されます。

 az aks get-credentials --resource-group KubernetesGroup --name verycoolcluster
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プライベートコンテナのdockerリポジトリにあるdockerイメージにアクセスするには、シークレットを作成する必要があります。 パブリックイメージがある場合は、この手順をスキップできます。

シークレットファイルを作成するには、次の形式のコマンドを実行する必要があります。

 kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イメージがdockerリポジトリにある場合、<your-registry-server>の値はhttps://index.docker.io/v1/になります

Azure Container Registryの場合、FQDNは<registry-name> .azurecr.ioになります

つまり、私の場合、コンテナのシークレットを作成するには、次のようにしました。

 kubectl create secret docker-registry regcred --docker-server="myservice.azurecr.io" --docker-username="myservice" --docker-password="PJSeyO9=lCMRDI7dGkz68wjhFGRGxSY3" --docker-email="asommer@yandex.ru"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のコマンドを使用して、作成されたシークレットファイルの内容を表示できます。

 kubectl get secret regcred --output=yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

情報

AKSを使用する場合、シークレットファイルを作成することはできませんが、別の方法で-ACRサービスへのアクセスを提供します-特別なスクリプトを実行します。 次のページから取得できます。

Azure Kubernetes ServiceからAzure Container Registryで認証する

 #!/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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AKS *変数とACR *変数の値を変更し、スクリプトをコピーしてAzure CLIまたはCloud Shellに貼り付けるだけです。

Kubernetesには、セキュリティで保護された資格情報ストアが含まれています。 つまり、設定を使用してファイルを作成でき、外部からこれらの設定にアクセスするのは困難です。 このファイルには通常、データベース接続文字列とクレジットが含まれています。 アプリケーションにそのような情報がない場合（本当ですか？）、この手順をスキップできます。

コマンドラインから設定ファイルを作成するには、まずviコマンドを検討する必要があります。

 vi < >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルがない場合、または既存のファイルを開く場合、ファイルを作成します

入力した変更を保存するには、ESCを押してからZZを押します

ESCを保存せずに単純に終了するには、次のようにします。q！

非常に短い説明ですが、それで十分でしょう。 Insertキーが非常に役立つことを追加できます。

そのため、Azure Cloud Shellを使用して、任意の名前（appsettings.jsonなど）と必要なコンテンツを含むファイルを作成します。 そのようなことを認めましょう：

 { "ConnectionString": "some secret string goes there" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コマンドを実行した後：

 kubectl create secret generic secret-appsettings --from-file=/home/youraccount/appsettings.json
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、secret-appsettingsという設定でシークレットを作成します

/ home / youraccountを置き換えるパスを見つけるには、pwdコマンドを使用します。

展開を作成する

デプロイメントはステートレスサービス用です。 ポッドとレプリカセットの作成方法と更新方法について説明します。 ポッドは、同じ環境で動作するコンテナのグループ（または1つのコンテナ）です。 ReplicaSetの目的は、指定された数のポッドが起動され、常に機能することを制御することです。

以前に作成したものに基づいて、3つのサブを作成するdeploy.yamlファイルを作成します。 このファイルには次のコードが含まれています（yamlのスペースは非常に重要です）。

 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードを検討してください。 最初に、レプリカの数と更新戦略について説明します。 次に、展開に名前（myapp）が与えられ、コンテナイメージへの参照が示されます。 ポートが登録されています。 80は、httpの標準ポートです。 次に、ASP.NET Core環境設定があります。 次に、プライベートドッカーイメージのクレジットと、最近作成したアプリケーションのシークレット設定がマウントされました。

  strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この部分は、アップグレードプロセスを担当します。 maxSurge-更新時に既存のものを超えて作成された炉床の数（単位またはパーセント）。 maxUnavailable-更新プロセス中に利用できなくなる可能性のある炉床の最大数。

次のコマンドを使用して展開を作成できます。

 kubectl apply -f deploy.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ingressに会う

クラスターサービスへのアクセスを提供し、負荷分散を整理するために、イングレスと呼ばれるサービスが使用されます。 かなり人気のあるソリューションは、nginxに基づくイングレスです。 最も簡単なインストール方法は、helmと呼ばれるKubernetesパッケージマネージャーを使用することです。 Azure Cloud Shellの利点は、ヘルムが既にインストールされていることです。 nginx-ingressをインストールするために残されていること。 以下を入力してください：

 helm init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し待ってから実行します：

 helm install stable/nginx-ingress --namespace kube-system --set rbac.create=false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LetsEncryptを使用したSSL証明書の作成

SSL証明書は何らかのドメイン名に関連付けられているため、DNSリソースに名前を付けます。

次のコマンドを実行して、外部IPを取得します

 kubectl get service -l app=nginx-ingress --namespace kube-system
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のスクリプトでサブドメイン用に発明したIPと名前を置き換えます

 #!/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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトをコピーして、コマンドラインに貼り付け、この方法で実行します。 サブドメインの名前として、非常に「元の」名前を設定します-myservice-ingress

次のスクリプトをコマンドラインにコピーアンドペーストして、同じ方法で証明書マネージャーをインストールします。 ここでは、特別な変更も必要ありません。

 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

情報

RBACを使用するクラスターがある場合、スクリプトは異なります。

 helm install stable/cert-manager --set ingressShim.defaultIssuerName=letsencrypt-staging --set ingressShim.defaultIssuerKind=ClusterIssuer
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

証明書ファイルが利用可能な場合、次のように追加できます。

 kubectl create secret tls tls-secret --cert CERT.crt --key KEY-FOR-CERT.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、署名されたCA証明書がないため、タンバリンと少し踊らなければなりません。 LetsEncryptと呼ばれる無料のサービスを使用してCAを作成します。 LetsEncryptは、証明書を無料で発行する認証局です。 インターネットを保護することを目標とする、このような利他的な組織。

したがって、cluster-issuer.yamlファイルを作成し、証明書を発行した組織を記述します。

 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: {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

電子メールを自分のアドレスに置き換えるだけで、次のことができます。

 kubectl apply -f cluster-issuer.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、作成されたClusterIssuerの名前と証明書の対象ドメインを指定してcertificate.yaml証明書ファイルを作成します-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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは実施します：

 kubectl apply -f certificate.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスの作成とイングレス

Kubernetesは、4種類のサービスを作成できます。

デフォルトのサービスはClusterIPです。 このサービスへのアクセスは、クラスターから内部IPを介してのみ可能です。

NodePortは、ClusterIPサービスを自動的に作成します。 NodePortへのアクセスは、次のルートにより外部から可能です。

LoadBalancerロードバランサーは、外部からのサービスへのアクセスを提供し、NodePortおよびClusterIPサービスを自動的に作成します。

ExternalNameは、サービスを外部名に関連付けます。

基本的なサービスで十分です：

 apiVersion: v1 kind: Service metadata: name: myservice spec: type: ClusterIP ports: - port: 80 name: http targetPort: http selector: app: myapp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

selectorの値を使用して、デプロイメントの名前を示します。

サービスを作成するために残ります

 kubectl apply -f service.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最終段階として、この記事で既に少し紹介したイングレスを作成します。 yamlでは、クラスター発行者の名前と証明書を指定します。 以前に作成しました。

 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じkubectl applyコマンドを使用してイングレスを作成してしばらくすると、マイクロサービスがhttps：// myservice-ingress.westeurope.cloudapp.azure.comで利用可能になります。 ブラウザのアドレスバーでhttpsの横にあるロックをクリックすると、証明書が有効であり、CAによって発行されていることを確認できます。

これはハッカー誌の記事の完全バージョンであることを思い出します。 著者はAlexey Sommerです。