はじめまして、富士通クラウドテクノロジーズの加藤壮悟です。
2021年卒の新入社員で、現在は Hatoba チームにて新人研修中です。
老後の夢は中華料理屋を開くことです。
よろしくお願いします。
さて、2021年7月、ニフクラ Kubernetes Service Hatoba に
type: LoadBalancer 機能が追加されました！
今回はその type: LoadBalancer を活用して、ログデータ検索や分析、可視化ツールの Elasticsearch と Kibana をデプロイし、公開してみたいと思います。
「type: LoadBalancer? なにそれおいしいの？」という人（Kubernetes歴 2週間の時の私）もそうじゃない人も、Kubernetes 歴 1か月の私がしっかり解説しますので、ぜひ試してみてください。
- ニフクラ Kubernetes Service Hatoba とは
- Kubernetes の type: LoadBalancer とは
- Elasticsearch と Kibana をデプロイしてみる
- おわりに
- 仕様
- 参考文献
ニフクラ Kubernetes Service Hatoba とは
ニフクラ Kubernetes Service Hatoba は、Kubernetes クラスターを簡単に構築・管理できるマネージドサービスです。Kubernetes の標準的な操作で、コンテナ化されたアプリケーションを、クラスター上にデプロイできます。
詳細については「機能・サービス：Kubernetes Service Hatoba」をご確認ください。
Kubernetes の type: LoadBalancer とは
Kubernetes 外部のロードバランサーを Kubernetes マニフェストの type フィールドに LoadBalancer と設定することで利用できます。
ニフクラ Kubernetes Service Hatoba （以降 Hatoba）上のクラスターで type: LoadBalancer を指定するとニフクラのL4ロードバランサーが作成され、それが Kubernetes の Service 用ロードバランサーとして紐づけられます。Service とは Kubernetes 上のコンテナ群（Pod と呼びます）で実行されているアプリケーションを公開するための方法です*1。
利用シーン
Kubernetes の type: LoadBalancer は Web サービスを外部に公開するときに便利です。
Elasticsearch と Kibana をデプロイしてみる
今回は、ログの検索・分析エンジンである Elasticsearch とデータの可視化ツール Kibana を Hatoba 上にデプロイし type: LoadBalancer を使って外部公開してみようと思います！
Hatoba に7月に追加された新機能 type: LoadBalancer を使うため、Elasticsearch と Kibana の構築さえしてしまえばアプリの公開はとても簡単です。
こちらは今回の構成のイメージになります。
手順
- ニフクラ上のリソース（プライベートLAN、ルーター、NAS）を作成
- Hatoba クラスターを作成
- ニフクラNASを PersistentVolume として使うための設定をする
- クラスター上に ECK (Elastic Cloud on Kubernetes) をデプロイする
- Elasticsearch と Kibana をデプロイする
※Kibana をtype: LoadBalancerで公開する - あそぶ
検証環境
| 項目 | 値 |
|---|---|
| リージョン | east-2 |
| ゾーン | east-21 |
| Kubernetes バージョン | 1.21.1 |
| Elasticsearch バージョン | 7.11.2 |
| Kibana バージョン | 7.11.2 |
- リージョン・ゾーンは任意で選んでいただいて構いませんが、リージョンにより使用可能な機能が異なります。ニフクラ ゾーン別機能対応表を参考に、ご希望のNASが利用可能なリージョン・ゾーンをご選択ください。
- お手元に
kubectlがインストールされた環境をご用意ください。
1. ニフクラ上のリソース（プライベートLAN、ルーター、NAS）を作成
まず今回のハンズオンで使うニフクラリソースを作成します。
Elasticsearch は PersistentVolume を使用しますが、今回はニフクラNASを利用したいと思います。
また、プライベートLANも設定し、Hatoba クラスターとNASが同一のネットワーク上にあるようにします。
1-1. プライベートLANの作成
サービス一覧から「ネットワーク」を選択します。
ネットワーク図が表示されている画面で「ネットワーク上での操作」のプルダウンから、「プライベートLAN作成」を選び、項目を入力します。
| 項目 | 値 |
|---|---|
| プライベートLAN名 | eck（任意の名前） |
| ゾーン | east-21（任意のゾーン） |
| CIDR | 192.168.0.0/16 |
1-2. ルーターの作成
ルーターの作成に先立って、DHCPコンフィグおよびDHCPオプションを設定します。
左メニューの「DHCPコンフィグ」から、「DHCPコンフィグ作成」をクリックし、「自動割り当てIPアドレス」を追加します。
下記の項目は、Hatoba で作成するクラスターのノードに割り振るIPアドレスです。項目を入力したら「作成する」をクリックします。
| 項目 | 値 |
|---|---|
| 開始IPアドレス | 192.168.1.0 |
| 終了IPアドレス | 192.168.1.255 |
左メニューの「DHCPオプション」から、「DHCPオプション作成」をクリックし「default-router」に 192.168.0.1 と入力します。他の項目は入力不要ですので、「作成する」をクリックします。
左メニューの「ネットワーク」をクリックし、「ネットワーク上での操作」のプルダウンから、「ルーター作成」を選択します。項目を下記の通り入力してください。
| 項目 | 値 |
|---|---|
| ルーター名 | router（任意） |
| ゾーン | east-21（プライベートLANと同じゾーン） |
| タイプ | router.small（任意） |
「ネットワーク設定へ」をクリックし、ルーターのネットワーク設定の画面へ進みます。「ネットワーク追加」をクリックし、下記の項目を入力します。
| 項目 | 値 |
|---|---|
| ネットワーク | 作成したプライベートLAN |
| IPアドレス（任意） | 192.168.0.1 |
| DHCP | 有効 |
| DHCPコンフィグ | 作成したDHCPコンフィグ |
| DHCPオプション | 作成したDHCPオプション |
「ファイアウォール設定へ」をクリックしますが、今回はプライベートネットワークにだけ接続するためファイアウォール設定なしで（「適用しない」を選択して）進めます。設定内容を確認し、ルーターを作成してください。
1-3. NASの作成
サービス一覧から「NAS」を選択します。
左メニューの「ファイアウォール」から「NASファイアウォールグループ作成」をクリックしてください。任意の名前を入力し、ゾーンを選択してから「作成する」をクリックします。
続いて、ルール変更の画面が表示されますので、接続を許可する接続元のIPアドレスの範囲として、Hatoba クラスターのIPアドレス範囲を指定します。入力が終わったら「追加」をクリックします。
| 項目 | 値 |
|---|---|
| 接続元種別 | CIDR |
| IPアドレス・グループ | 192.168.1.0/24 |
次にNASの作成を行います。左メニューの「NAS」を選択し、「NAS作成」をクリックしてください。
NFSの高速タイプもしくは標準タイプを選択します。
基本設定を下記のとおり行ってください。
| 項目 | 値 |
|---|---|
| NAS名 | eck（任意の名前） |
| ゾーン | east-21（プライベートLANと同じゾーン） |
| NAS容量 | 100GB（任意の容量） |
| NASファイアウォールグループ名 | 作成したNASファイアウォールグループ |
| プライベート側ネットワーク | 作成したプライベートLAN |
| プライベートIPアドレス | 192.168.100.1/16 |
NASの作成が完了したら、そのNASを選択し、「選択したNASの操作」のプルダウンから、「設定変更」を選びます。
設定変更画面で、「root squash設定」を「root_squash」から「no_root_squash」に変更します。この設定により、Kubernetes が nobody 以外のユーザー名でのファイルの書き込みできるようになります。root squash について詳しくはニフクラNAS（NFS）のアクセス権限についての FAQ ページをご確認ください。
2. Hatoba クラスターを作成
2-1．Hatoba ファイアウォール作成
サービス一覧から「Kubernetes Service Hatoba」を選択します。
左メニューの「ファイアウォール」から「ファイアウォールグループ作成」をクリックします。ファイアウォールグループ名は任意の名前を入力してください。
続いて、ファイアウォールグループに IN ルールを追加します。「選択したファイアウォールグループの操作」のプルダウンから、「INルール設定の追加」を選びます。
下記のように IN ルールを設定してください。
| 項目 | 値 |
|---|---|
| プロトコル | TCP |
| ポート | 6443 - 6443 |
| CIDR | xxx.xxx.xxx.xxx/xx（適宜調整してください） |
2-2. Hatoba クラスター作成
左メニューの「クラスター」から「クラスター作成」をクリックします。各項目を下記の通り入力します。
| 項目 | 値 |
|---|---|
| クラスター名 | eck（任意の名前） |
| ゾーン | east-21（プライベートLANと同じゾーン） |
| プライベートLAN | 作成したプライベートLAN |
| ファイアウォールグループ | 作成したファイアウォールグループ |
| Kubernetesのバージョン | v1.21.1（任意のバージョン） |
| HTTPロードバランサー | 利用しない |
「ノードプール設定へ」をクリックし、続けて「ノードプール追加」をクリックしてください。
| 項目 | 値 |
|---|---|
| ノードプール名 | nodepool（任意の名前） |
| サーバータイプ | e-medium8（メモリ8GBのものを推奨） |
| ノード数 | 3（任意の数） |
2-3. Hatoba クラスターのクレデンシャルを登録する
Hatoba クラスターの作成が完了したら、該当のクラスターを選択し、「選択したクラスターの操作」のプルダウンから「クレデンシャル表示」を選びます。この内容をすべてコピーし ~/.kube/config に保存してください。
3. ニフクラNASを PersistentVolume として使うための設定をする
Elasticsearch ではデータの永続化のために PersistentVolume を使用します。このステップでは Kubernetes NFS Subdir External Provisioner を使って、先ほど作成したニフクラNASを PersistentVolume としてプロビジョニングします。
Kubernetes NFS Subdir External Provisioner の Helm を使わない手順を進めていきます。
3-1. リポジトリをクローン
任意のディレクトリに Kubernetes NFS Subdir External Provisioner をクローンします。
$ git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git
$ cd nfs-subdir-external-provisioner/
3-2. 認証を設定
# RBAC オブジェクトの subject を provisioner がデプロイされる現在の namespace の値に設定する $ NS=$(kubectl config get-contexts|grep -e "^\*" |awk '{print $5}') $ NAMESPACE=${NS:-default} $ sed -i'' "s/namespace:.*/namespace: $NAMESPACE/g" ./deploy/rbac.yaml ./deploy/deployment.yaml
$ kubectl create -f deploy/rbac.yaml
serviceaccount/nfs-client-provisioner created
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
3-3. NFS subdir external provisioner の構成をする
deploy/deployment.yaml を編集します。NFS_SERVER NFS_PATH の値を変更します（修正箇所は4か所）。
$ sed -i'' "s/10.3.243.101/192.168.100.1/g" ./deploy/deployment.yaml $ sed -i'' "s/\/ifs\/kubernetes/\//g" ./deploy/deployment.yaml
編集後の deploy/deployment.yaml は以下のようになります。
apiVersion: apps/v1 kind: Deployment metadata: name: nfs-client-provisioner labels: app: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: default spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: nfs-client-provisioner template: metadata: labels: app: nfs-client-provisioner spec: serviceAccountName: nfs-client-provisioner containers: - name: nfs-client-provisioner image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME value: k8s-sigs.io/nfs-subdir-external-provisioner - name: NFS_SERVER value: 192.168.100.1 - name: NFS_PATH value: / volumes: - name: nfs-client-root nfs: server: 192.168.100.1 path: /
kubectl apply しておきます
$ kubectl apply -f deploy/deployment.yaml
deployment.apps/nfs-client-provisioner created
3-4. StorageClass をデプロイ
$ kubectl apply -f deploy/class.yaml
storageclass.storage.k8s.io/managed-nfs-storage created
3-5. テストしてみる
$ kubectl create -f deploy/test-claim.yaml -f deploy/test-pod.yaml persistentvolumeclaim/test-claim created pod/test-pod created
kubectl get po や kubectl get pv を実行してみて、異常がなさそうであれば大丈夫です。
$ kubectl get po NAME READY STATUS RESTARTS AGE nfs-client-provisioner-7d494d96d4-wqm2b 1/1 Running 0 108s test-pod 0/1 Completed 0 27s $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-77de7867-eb71-4f1e-a62c-a655b0314d8b 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 38s
$ kubectl delete -f deploy/test-pod.yaml -f deploy/test-claim.yaml pod "test-pod" deleted persistentvolumeclaim "test-claim" deleted
3-6. managed-nfs-storage をデフォルトの StorageClass にする
3-5 で作成した PersistentVolumeClaim test-claim では明示的に storageClassName を指定し、 PersistentVolume を作成させていました。storageClassName は省略可能なパラメータで、省略するとクラスターに設定されたデフォルトの StorageClass を使用します。
ECK のマニフェストでも storageClassName を指定できますが、ここから先 managed-nfs-storage の StorageClass しか使用しないため、 managed-nfs-storage をデフォルトの StorageClass として設定します。
# 現在の状態を確認 $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage k8s-sigs.io/nfs-subdir-external-provisioner Delete Immediate false 92m # 変更 $ kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' storageclass.storage.k8s.io/managed-nfs-storage patched # 再度確認してみる $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage (default) k8s-sigs.io/nfs-subdir-external-provisioner Delete Immediate false 93m
4. クラスター上に ECK (Elastic Cloud on Kubernetes) をデプロイする
Elastic Cloud on Kubernetes (以下、ECK) とは、Elasticsearch や Kibana 等の Elastic 社の製品のセットアップやアップグレードといった管理をシンプルにしてくれるソフトウェアです。
ECK をデプロイするには下記のコマンドを実行してください*2。
$ kubectl create -f https://download.elastic.co/downloads/eck/1.7.0/crds.yaml customresourcedefinition.apiextensions.k8s.io/agents.agent.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/apmservers.apm.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/beats.beat.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/elasticmapsservers.maps.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/elasticsearches.elasticsearch.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/enterprisesearches.enterprisesearch.k8s.elastic.co created customresourcedefinition.apiextensions.k8s.io/kibanas.kibana.k8s.elastic.co created
$ kubectl apply -f https://download.elastic.co/downloads/eck/1.7.0/operator.yaml namespace/elastic-system created serviceaccount/elastic-operator created secret/elastic-webhook-server-cert created configmap/elastic-operator created clusterrole.rbac.authorization.k8s.io/elastic-operator created clusterrole.rbac.authorization.k8s.io/elastic-operator-view created clusterrole.rbac.authorization.k8s.io/elastic-operator-edit created clusterrolebinding.rbac.authorization.k8s.io/elastic-operator created service/elastic-webhook-server created statefulset.apps/elastic-operator created validatingwebhookconfiguration.admissionregistration.k8s.io/elastic-webhook.k8s.elastic.co created
5. Elasticsearch と Kibana をデプロイする（Kibana を type: LoadBalancer で公開する）
5-1．マニフェストを作成
Elasticsearch をデプロイするためのマニフェストを作成します*3。
cat <<EOF | tee ./elasticsearch.yaml apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: quickstart spec: version: 7.11.2 nodeSets: - name: default count: 1 config: node.store.allow_mmap: false podTemplate: spec: containers: - name: elasticsearch env: - name: ES_JAVA_OPTS value: -Xms2g -Xmx2g resources: requests: memory: 4Gi limits: memory: 4Gi EOF
ここで2点ほど注意点があります。
バージョンを
7.11.2としています Hatoba で作成される Kubernetes クラスターが使用しているコンテナランタイムと JDK の相性が悪く、うまく動作しない問題を回避するためです。（2021年9月現在）*4メモリの制限を4GBまで上げています Elasticsearch はメモリを大量消費するため、デフォルトの 1GB の制限だとOOM キラーによって殺されてしまいます。 Elastic 社の公式ドキュメントに記載の方法を参考に対処しています。
次に、Kibana のマニフェストを作成します*5。
cat <<EOF | tee ./kibana.yaml apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: quickstart spec: version: 7.11.2 count: 1 elasticsearchRef: name: quickstart http: service: spec: type: LoadBalancer # default is ClusterIP metadata: annotations: service.beta.kubernetes.io/hatoba-load-balancer-name: kibanalb tls: selfSignedCertificate: disabled: true EOF
このマニフェストに type: LoadBalancer の字が見えると思います。
そう、これが type: LoadBalancer です。
また、annotations に Hatoba のコントロールパネル上で表示されるロードバランサーの名前をつけています。名前の文字列には英数小文字のみ使用可能です。
5-2. Elasticsearch をデプロイ
マニフェストを適用します。
$ kubectl apply -f elasticsearch.yaml
elasticsearch.elasticsearch.k8s.elastic.co/quickstart created
Elasticsearch の状態を確認します。HEALTH が green ならOKです。
$ kubectl get elasticsearch NAME HEALTH NODES VERSION PHASE AGE quickstart green 1 7.11.2 Ready 2m8s
5-3. Kibana をデプロイ
マニフェストを適用します。
$ kubectl apply -f kibana.yaml
kibana.kibana.k8s.elastic.co/qu
同様に Kibana の状態を確認します。HEALTH が green ならOKです。
$ kubectl get kibana NAME HEALTH NODES VERSION AGE quickstart green 1 7.11.2 72s
6. あそぶ
これでめでたく、Elasticsearch と Kibana がデプロイされ、Hatoba の新機能 type: LoadBalancer によって Kibana が外部公開されましたので、さっそく遊んでみましょう！
6-1. IPアドレスを確認
ロードバランサーのIPアドレスは kubectl get svc して quickstart-kb-http の EXTERNAL-IP を確認するか、ニフクラのコントロールパネルから確認します。
6-2. パスワードを確認
Kibana のデフォルトパスワードを確認します。
$ kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode; echo <パスワード>
6-3. ログインする
http://<ロードバランサーのIPアドレス>:5601 にアクセスします。
ログイン画面が表示されますので、ユーザー名 elastic と入力し、パスワードは 6-2 で確認したものを入れます。
6-4. あそぶ！
お疲れ様でした！
あとはサンプルデータをいじってみたり、自分のデータを入れるなどして遊んでみてください。
おわりに
少し長くなってしまいましたが、皆さんは無事に完了しましたか？
K8s 初心者の私が検証した際には Elasticsearch のデプロイにハマりにハマりましたが、この記事のメインディッシュである type: LoadBalancer は驚くほど簡単にデプロイできました。文字通り type: LoadBalancer って入れるだけですからね。
type: LoadBalancer は Kubernetes で何か Web アプリケーションをデプロイするなら、とても「欲しい！」機能なのではないでしょうか？
よりパワーアップした Hatoba で、皆さん良い Kubernetes ライフを！
仕様
ニフクラ Kubernetes Service Hatoba のロードバランサーについての技術仕様はニフクラ Kubernetes Service Hatoba：ロードバランサーのページをご確認ください。
