Kubernetes(k8s)を学ぼう! Microservices編~アプリケーションのデプロイ~

こんにちは。KOUKIです。k8s学習中のWebエンジニアです。

KubernetesでMicroservicesのデプロイ方法を学びましょう。

本記事では、たくさんのアプリケーションをデプロイします。

尚、今回もMinikubeを使いますので、以下の記事でインストール&起動してください。
※ MacおよびChromeで検証します。

参考

Udemyの「Kubernetes Hands-On – Deploy Microservices to the AWS Cloud」コースを参考にしています。

解釈は私が勝手に付けているので、本物をみたい場合は受講してみてください。

API OVERVIEWも参考になります。

今回は、たくさんのサービスをデプロイします。
GitHub: https://github.com/DickChesterwood/k8s-fleetman

講義によると、以下のような構成になります。

前回

現在の状況は、以下のようになってます。

環境構築

これからたくさんのServiceやPodをデプロイしていきます。

クリーンアップ

前回構築したServiceやPodを以下のコマンドで削除します。

DeploymentにReplicasetを指定していますが、Deployment自体を消せばPodの復活はできないようですね。

また、以下のファイルはもういらないので、削除しておきましょう。

また、以前作成したpods.ymのファイル名を以下のように変更します。

workloadsのデプロイ

workloadsを作成します。

Serviceのデプロイ

Serviceも作成しましょう。

fleetman-queues Serviceに、endpoint(port:61616)を追加してます。

Serviceの立ち上げ

下記のコマンドで、Serviceを立ち上げます。

「http://192.168.99.102:30010/」の方では、ActiveMQ画面が確認できます。

http://192.168.99.102:32209」は無視してください。

position-simulator Serviceの立ち上げとログ調査

次は、position-simulator Serviceを立ち上げたいと思います。

まずは、Deploymentからです。

envに設定しているvalue(production-ihpfiohaposijfpoa)は適当な値です。これから立ち上げるPodをエラーの状態にしたいので、誤りの値を入れています。

以下のコマンドで、applyしましょう。

ログ調査 – 現状の確認

ここで少し、ログ調査について触れておきます。

以下のコマンドで、position-simulator podの様子を確認しましょう。

position-simulator-5f7bbd8566-cwmsv」のSTATUSがErrorになっています。

ログ調査 – 詳細を確認する

詳細を確認するために、以下のコマンドを実行しましょう。

この最後の「Events」部分に着目して欲しいです。ここで、Podに何が起こったのか、その情報が記述されます。

Back-off restarting failed container」となっているので、何かしらの問題が発生したようです。

ログ調査 – ログを出力

下記のコマンドで、ログを出力することができます。

おお、素晴らしいですね。

このアプリケーションは、JavaのフレームワークであるSpringで動いているようですね。

そして、ログには以下の出力がされています。

2021-11-04 19:24:00.961 INFO 1 — [ main] c.v.s.PositionsimulatorApplication : The following profiles are active: production-ihpfiohaposijfpoa

production-ihpfiohaposijfpoa」は、workloads.ymlのenvに設定した値ですね。この値をSpringアプリケーションが読み込んでいます。

その後、クラッシュを引き起こしていることからこの値に何か問題があるのかと推察できます。

ログ調査 – 解決

workloads.ymlのenvに設定したvalueを変更します。

production-microservice」が正しい値らしいです。

applyします。

position-simulatorのSTATUSが「Running」になったので、今度はOKですね。

position-tracker Deploymentのデプロイ

続いて、position-trackerをデプロイします。

内容はこれまで実装した他のDeploymentとほぼ同じです。記述が重複するので、Helmなどのツールが使われるようですね。

applyしましょう。

一旦、動作確認をしてみましょう。

下記のコマンドで、minikubeのipを確認します。

このIPで、ブラウザから「http://192.168.99.102:30010」にアクセスし、Active MQの画面を表示させます。

続いて、「Manage ActiveMQ broker」を押下し、ユーザー名とパスワードに「admin」を入力してログインします。

すると以下の画面に飛ぶので、「Queues」をクリックします。

OKですね。

position-tracker Serviceのデプロイ

続いて、Serviceをデプロイします。

applyします。

ローカルから「http://192.168.99.102:30020/」にアクセスします。

アプリが反応しなくなりました。。。

minikube環境の再作成

どうやらたくさんのアプリをデプロイする関係で、minikube上のメモリが足りなくなったようです。

そこで、minikubeの環境を作り直します。

ブラウザから「http://192.168.99.103:30020/」にアクセスします。

今後は、OKでした。

エラーが表示されますが、「http://192.168.99.103:30020/vehicles/City%20Truck」のようにパラメータをつけてリクエストを送ると情報が取得できます。

データの取得が確認できました。しか足、position-tracker Serviceは外部(ブラウザ)に公開する必要がないので(アプリ内からの利用)、TypeをClusterIPに変更して外部に公開できないようします。

fleetman-position-tracker」のPORTが「8080/TCP 」のみになりましたので、OKですね。

API Gatewayのデプロイ

続いて、API Gatewayをデプロイしましょう。

もう何度も同じ手順を繰り返してますね^^

applyします。

ブラウザから「http://192.168.99.103:30020/」にアクセスします。

Api Gatewayのインターフェースっぽいものが出て来ました。

Web Appのデプロイ

最後にWeb Appをデプロイして終わりにしましょう。

Web AppのServiceは既に定義済みなので、Deploymentだけapplyします。

Web Appが立ち上がったらブラウザから「http://192.168.99.103:30080/」にアクセスしましょう。

OKですね。

長くなりましたが、これで以上です。

次回

次回は、Volumesについて学びましょう。

記事まとめ

参考

コード

services.yml

workloads.yml

コメントを残す