5 つのステップで Spring Boot サービスを Kubernetes に移行する

多くの Java 開発者は Spring Framework を使用して Web サービスを迅速に作成していますが、ランタイムとクラウド プロバイダーが多数存在するため、本番環境で実行することが困難な場合があります。もちろん、AWS Elastic Beanstalk などのサービスを使用して、自動スケーリング、ダウンタイムなしのデプロイメント、インフラストラクチャの新しいバージョンのデプロイメントが不要などの機能を備え、稼働を継続することもできます。しかし、これらのサービスは、予算が少ない人にとっては多額の費用がかかり、サービス インフラストラクチャを制御できなくなります。

予算が限られていて、低コストで Elastic Beanstalk のすべてのメリットを実現したい場合は、オープンソースの Kubernetes を使用できます。

1. Dockerイメージを生成する

Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するコンテナ オーケストレーション プラットフォームです。 Kubernetes は次のように動作します。アプリケーションから Docker イメージを作成し、作成したイメージのインスタンスを 1 つ以上起動するように Kubernetes に「指示」します。 Kubernetes はこれらのインスタンスを利用可能なノードに自動的に割り当て、常に実行されるようにします。ノードに障害が発生した場合、またはアプリケーションを拡張する必要がある場合、Kubernetes はインスタンスを自動的に再割り当てし、アプリケーションが常に利用可能であることを保証します。したがって、最初のステップは、Spring Boot サービスからイメージを作成することです。

以下は Dockerfile の例です。

 FROM openjdk:8-jdk-alpine VOLUME /tmp MAINTAINER Samuel Birocchi <[email protected]> ADD target/*.jar app.jar COPY newrelic newrelic ENV JAVA_OPTS="" ENV SPRING_PROFILE="default" ENV MONGO_PASSWORD="" ENTRYPOINT exec java $JAVA_OPTS \ -javaagent:newrelic/newrelic.jar \ -Djava.security.egd=file:/dev/./urandom \ -Dspring.profiles.active=$SPRING_PROFILE \ -Dmongo.password=$MONGO_PASSWORD \ -jar app.jar

これと docker build プラグインを使用すると、gradle clean buildDocker (または maven docker プラグイン) を実行して、docker イメージをビルドできます。 gradle.properties または build.gradle でバージョン タグが設定されたイメージが作成されることに注意してください。

2. デプロイメントとポッドを作成する

作成したイメージを Kubernetes に配置するには、レジストリにアップロードする必要があります。パブリック Docker レジストリにアップロードすることもできますが、その場合、イメージは誰でも利用できるようになります。私たちのサービスはプライベートなので、プライベートレジストリにアップロードする必要があります。幸いなことに、Gcloud はアカウント用のプライベート レジストリを提供します。

このようにして、最終的に Kubernetes クラスターにサービスを配置できます。 Gcloud を使用しているため、GKE を使用してクラスターを作成するのは非常に簡単です。このチュートリアルに従ってください。クラスターを作成し、それに接続するためのコマンド ラインを構成した後、アプリケーションのスケーラビリティを実現するために、デプロイメント (またはレプリケーション コントローラー) を作成する必要があります。初期設定として次の設定を使用します。

 apiVersion: apps/v1beta1 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment metadata: name: spring-boot-deployment spec: selector: matchLabels: app: spring-boot-app replicas: 3 # tells deployment to run 3 pods matching the template template: # create pods using pod definition in this template metadata: labels: app: spring-boot-app spec: containers: - name: spring-boot-app image: #your image name here ports: - containerPort: 8080 name: server - containerPort: 8081 name: management

最後の手順で Kubernetes コマンドライン インターフェイス (kubectl) を構成したことを考慮すると、Kubernetes クラスターの新しいデプロイメントを作成し、 kubectl apply -f Deployment.yml を使用してこの構成を使用できます。しばらくすると、 kubectl get deployment spring-boot-deployment でデプロイメントのステータスを確認でき、 kubectl get pods spring-boot-app でポッドのステータスを確認できます。ポッドのログを確認する場合は、kubectl log コマンドを使用できます。

3. サービスを使用してポッドを公開する

Pod が実行されるようになったので、Pod を一般に公開するためのサービスを作成する必要があります。次の構成でサービスを作成します。

 apiVersion: v1 kind: Service metadata: name: spring-boot-service spec: ports: - port: 8080 targetPort: 8080 name: http - port: 8081 targetPort: 8081 name: management selector: app: spring-boot-app type: NodePort

ご覧のとおり、サービス構成は非常にシンプルです。ただし、この構成は公開されていません。 gcloud はサービス用の実際のロードバランサと外部 IP を自動的に作成するため、サービス タイプを LoadBalancer に設定できます。実際にこの構成を使用しようとすると、TLS と HTTPS を正しく設定できず、サービスに HTTPS プロトコル経由でのみアクセスできるようにする必要があります。しかし、どうやってそれをするのでしょうか?

4. Ingressを使用したルーティング

使用する Kubernetes Ingress を見つけることができます。これは新しい機能ですが、非常に効果的です。これは LoadBalancer タイプのサービスとほぼ同じですが、カスタム ルーティング ルールを設定できます。以下は Ingress 構成です。

 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: spring-boot-ingress annotations: kubernetes.io/ingress.allow-http: "false" spec: tls: - secretName: your-tls-secret backend: serviceName: spring-boot-service servicePort: 8080

ご覧のとおり、 kubernetes.io/ingress.allow-http: "false" を使用して、Ingress が HTTPS 接続のみを許可するように設定しています。ただし、このファイルには TLS 構成があることがわかります。まず、Ingress アクセス用の SSL 証明書データを含む Secret を作成する必要があります。これは以下の設定を使用して実行できます。

5. 秘密

apiVersion: v1 data: tls.crt: #base64 hash of your cert tls.key: #base64 hash of your key kind: Secret metadata: name: your-tls-secret namespace: default type: Opaque

すべての設定を適用した後、kubectl get ingress spring-boot-ingress コマンドを使用してアプリケーションの外部 IP を確認できます。 HTTPS 経由でアクセスすると、Spring Boot アプリケーションが Kubernetes クラスター上で実行されるようになりました。

重要！ Kubernetes サービスは、デフォルトのポッド ポートとエンドポイント「/」に対してヘルス チェックを実行します。そのエンドポイントがマップされていないか保護されている場合は、livenessProbe および readinessProbe 構成を含める必要があります。

Kubernetes 環境に慣れるために、本番環境にデプロイする前に minikube を使用してこれらの設定をテストすることをお勧めします。

新しいバージョンをデプロイするには、kubectl set image deployment/spring-boot-deployment spring-boot-app=your-new-image を使用するか、kubectl edit deploy spring-boot-deployment で構成を編集します。 2 番目のコマンドを使用すると、イメージと Pod の数を同時に更新できます。アプリケーションをスケーリングするだけの場合は、kubectl scale deployment spring-boot-deployment --replicas=10 を実行するか、自動スケーリング構成を作成します。

デプロイメントを更新すると、Kubernetes のローリング アップデートが実行され、すべてが処理されるためダウンタイムは発生しません。そのため、ユーザーはただ座ってリラックスするだけで済みます。インフラストラクチャを GKE に変更すると、アプリケーションの健全性よりも開発に重点を置くことができます。 Kubernetes は、Jenkins、GitLab CI、BitBucket Pipelines などの CI ツールと組み合わせて使用​​すると非常に簡単です。