このブログは、コンテナのオーケストレーターであるkubernetesについて
自分の知識をまとめることを目的として記事を書いています。
もともとなが～くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や
相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。
前回までで、Kubernetesの構築、Pod、Service、永続ボリュームの利用を説明しました。
vSphereでいうところの、ESXiをインストールしてVCを構築して統合管理を行い、ストレージ
の設定してデータストアを作成し、仮想マシンを作って起動したというところですね。
基本的なことはできるようになっていますが、自分で作ったkubernetesの場合は便利な機能が
使えない状態になっています。
例えば、ServiceにはLoadBalancerというタイプのものがあります。
これを作成してみましょう。
以下のyamlを用意し、kubectl apply -f を実行します。
---
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
---
無事作成できたように見えますが、状態を見てみると以下の様にいつまでもEXTERNAL-IPが<pending>のままです。
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 27h
test-svc-1 LoadBalancer 10.107.138.238 <pending> 80:31352/TCP 7s
当然外部からアクセスするIPアドレスがないので通信ができません。
このように、手動作成のKubernetesには一部機能が備わっていなくてそのままだと使えないものがあるという状態です。
今回例として挙げた、ServiceのLoadBalancerタイプですが、以下の様な動作でユーザーからのアクセスをさばいてくれます。
<ユーザー>
→<Service:LoadBalancer>
→<Kubernetesクラスタノードのどれか>
→<Serviceと紐ついているPodのどれか>
つまり、ユーザーとKubernetesクラスタの間にLoadBalancerが入って、ユーザーからのアクセスをNodePortdで待ち構えるKubernetesクラスタのノードどれかに渡します。
ユーザーはLoadBalancerのIPにアクセスすればいいわけですから、KubernetesクラスタのノードのIPアドレスが変わっても特に意識することがなくなります。
勘のいい方は、えっそれって・・・と思われたかもしれません。
そうです。Kubernetesクラスタの外部にLB立ってます。
なので、手動で構築したままのKubernetesクラスタでServiceのLoadBalancerを作成しても、連携してくれるLoadBalancerがいないので、EXTERNAL-IPが<pending>のままになってしまうのです。
しかし、それをどうにかやってくれるありがたい存在があります。
その名をMetalLB、来月はこのMetalLBをどのように導入してどのように使うのかについて解説したいと思います。
ちなみに、マネージドkubernetes(GCPやAWS等で提供されているKubernetes)は、ServiceのLoadBalancerが作成されると連携してLoadBalancerが展開されます。
この辺の管理も含めて便利になっているのがサービスとして提供されているKuberneteのいいところですね。
