このブログは、コンテナのオーケストレーターであるkubernetesについて
自分の知識をまとめることを目的として記事を書いています。
もともとなが～くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や
相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。
前回、ServiceのタイプLoadBalancerは手動で作っただけのkubernetesでは使えないこと、
このServiceと連携してくれるLoadBalancerが必要となってしまうことをお話ししました。
今回ですが、kubernetesの外にあるLoadBalancerと連携するのではなく、kubernetes上に
LoadBalancerを用意して、ServiceのタイプLoadBalancerを動かしてしまえるMetalLBを
導入してみたいと思います。
MetalLBの公式はこちら
https://metallb.universe.tf/
公式に案内されていることをやれば動いてくれます。
早速作ってみましょう。
まず、MetalLBで払い出してもらうIPアドレスのレンジを決めます。
今回は192.168.0.200-192.168.0.210としました。
以下が設定となるConfigMapのyaml内容です。
configmap.yml
----
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.0.200-192.168.0.210
----
インストールをしていきます。
MetalLB用のnamespaceを作成するyamlがあるので使用して作成します。
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
名前空間ができているはずなので、kubectl get nsで名前空間を確認してみます。
NAME STATUS AGE
----
default Active 37d
kube-node-lease Active 37d
kube-public Active 37d
kube-system Active 37d
metallb-system Active 53s ※新しく作成された名前空間
----
MetalLBを作成します。
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl apply -f configmap.yml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
これでMetalLBが作成されています。
先ほど作成した名前空間「metallb-system」を指定してPodを見てみると
kubectl get pod,svc -n metallb-system
NAME READY STATUS RESTARTS AGE
pod/controller-fb659dc8-nf5xp 1/1 Running 0 9m34s
pod/speaker-5km2t 1/1 Running 0 9m34s
pod/speaker-7gkzv 1/1 Running 0 9m34s
pod/speaker-gbx4d 1/1 Running 0 9m34s
このようにMetalLB用のPodが作成されているのがわかります。
それでは、ServiceのタイプLoadBarancerを作成して、外部アクセス用のIPアドレスが割り当てられるか見てみましよう。
前回使用したServiceを作成するのですが、確認用のPodも作成しようと思います。
今までの流れだと2個のyamlを使用していましたが、実はyamlは「---」を使用して一つにまとめることができます。
具体的には以下のような形となります。
pod.yaml
---
kind: Pod
apiVersion: v1
metadata:
name: test-pod
labels:
site: test
spec:
containers:
- image: nginx
name: nginx-container
---
kind: Service
apiVersion: v1
metadata:
name: test-svc-1
labels:
app: test
site: test
spec:
type: LoadBalancer
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
site: test
---
ではこちらのファイルを元に作成を行ってみましょう。
kubectl apply -f pod.yaml
pod/test-pod created
service/test-svc-1 created
このように、PodとServiceが作成されていることがわかります。
MetalLBのyamlを使用して導入した際にも同じように複数のリソースを作成した出力結果
が出てきたと思いますが、あちらで使用したyamlファイルにも同様に複数のリソースを
1つのyamlにまとめていたからということです。
では、PodとServiceの状態を見てみましょう
kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/test-pod 1/1 Running 0 61s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 37d
service/test-svc-1 LoadBalancer 10.100.102.86 192.168.0.200 80:32383/TCP 61s
どうでしょう、作成したService「test-svc-1」にEXTERNAL-IPが割り当てられていると思います。
ここでは、tcp:80番で192.168.0.200にアクセスした場合にPodに転送されるようになっているはずです。
実際に通信可能な作業PCなどからブラウザでhttpでの通信をしてみてください。
nginxのデフォルトページが表示されると思います。
無事、ServiceタイプLoadBalancerが利用可能になりました。
これにより、IngressによるL7通信制御などもnginxのコントローラーを導入するとことで利用が
可能となり、やれることの範囲が広がっていきます。
ここで、タイトルにある時々vSphereのvSphere部分を無理やり書いてみると、vSphereのTanzuでは
この部分はNSX、HAproxy、Aviのどれかを選んで構築することになる部分となります。
VCとESXiだけではロードバランサーの役割はさすがに果たせないので仕方ない部分だと思いますが、
その分構築が複雑なのとライセンスでお金かかっちゃうのがネックですね・・・
今回は以上となります。
次回は永続ボリュームに関する『そのままだとできないこと』について書きたいと思います。
