Service

諸般の事情・・・というか単純に本ブログを動かしていたサーバーがどうやら壊れたようで(すぐに作業できる場所に置いてない)、とりあえずクラウド上に同じような環境を作ってバックアップからリストアしたんですが、最後にバックアップ取ってから何本か記事を書いていた物が消失しました。 皆さんちゃんとバックアップは定期的にとりましょう。 以上です。

TR;DR KubernetesのServiceで、Internal LoadBalancerってのがあるので、それを使うと良い Internal LoadBalancer 皆さんはEKS、もう使ってますか？私は使っています。業務システムをリプレースで新規開発する的な案件で、新システムの基盤がEKSという感じです。EKSはネットワークが素敵に気持ち悪い感じになっており、普通はKubernetesのクラスタ内部っていうのは、外側と別のサブネットを作る訳なんですが、なんとEKSが所属するVPCと同じサブネットで接続できるようになっています。 そんなわけで、同一VPCに存在したり、VPC PeeringしたりなんかしちゃってるEC2インスタンスとEKS上のPodはIPアドレスベースでは普通に接続がとれちゃったりするんです。 EKS上のアプリケーションから、EC2インスタンスへアクセスしたいときは、普通にEC2インスタンスのIPアドレスやら内部エンドポイントへアクセスすれば良いですね。EC2インスタンスが動きっぱなしならまぁさほどIPも変わらんでしょう(雑)。 しかし逆は問題です。PodのIPは勿論割り振られてはいますけれど、これはPodが再生成されると勿論変わってしまいます。アプリケーションは動きっぱなしだから変わらない、なんて言うこともできないです。EC2インスタンスはインスタンス上でアプリケーションの更新なんかもしちゃうかもしれないですけど、EKS上のPodに乗ったアプリケーションの更新は普通、Podの再作成が伴います。Podの再作成が起きると、勿論IPが変わります。 そうすると、やはり考えるのはServiceをつくることですね。外部からアクセスするためにはそうしますから、同じように考えるのが普通です。 しかし、ここで問題が発生します。普通に外部向けに公開するのと同じようにServiceを作成すると、グローバルIPが当たってしまい、プライベートIPベースで接続できる状況では接続ができないのです。困った。 まぁドキュメントちゃんと読めよって話なんですが、Kubernetesのドキュメント を読むと、Internal LoadBalancerってのがちゃんと書いてあります。AWSの方のドキュメントには無かったのでちょっと盲点でした。annotationで次の様に指定します。 1 2 3 4 5 6 # ... metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 # ... これだけで、type: LoadBalancerで作成されるELBが内部向けのものになります。internal-なんちゃらみたいなエンドポイントです。IPアドレスもしっかりプライベートIPです。最高。後ろの0.0.0.0/0のところで、アクセスできるIPレンジ制限できるのかなーなんて希望的観測を持ちましたが、全然関係ありませんでした。 ちょっと気持ち悪いのは、普通にパブリックDNSで名前引きができてしまうことですかね。全然関係ない外部のネットワークとかでも(パブリックDNSに名前があるので)名前解決ができてしまって、かつプライベートのアドレスが帰って来るという不思議な体験をすることができます。 1 2 3 4 5 6 7 8 9 10 11 $ nslookup internal-xxxxx.us-west-2.elb.amazonaws.com 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.187.214 Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.222.128 Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.109.84 うーん、まぁ実害は無いんでしょうけど。 ...

TL;DR Service type: ExternalNameを使用する External Service Kubernetes では、Ingress を使用することで、ホスト名ベースのロードバランシング/リバースプロキシを行うことが出来ます。その際、プロキシ先としてKubernetes上のService を指定するのですが、場合によってはKubernetesクラスタ外のサービスをプロキシ先としたい場合があります。例えば、弊宅の環境では、次の様にプロキシしています。 基盤であるOpenNebulaのダッシュボード以外は*.web-apps.techとして、Kubernetesへとルーティングしています。 ところで、本ブログは現在Kubernetes上へ移行作業中です。今のところはまだ、Kubernetes上へ載せていません。しかし、折角プロキシの設定が減っているので、blog.web-apps.techもIngressリソースとして管理したいです。 そこで使用できるのがService type: ExternalNameです。ExternalNameとして外部サービスを登録することで、Ingressのバックエンドとして使用できるようになります。 設定 設定はごく簡単で、次の様にします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 --- apiVersion: v1 kind: Namespace metadata: name: external-services --- apiVersion: v1 kind: Service metadata: name: ghost namespace: external-services spec: type: ExternalName externalName: 192.168.1.41 # 本ブログのローカルIP 今後も何かの拍子でKubernetesに載せたくないサービスが増える可能性もあるため、external-servicesとして名前空間を分離しました。このように設定すると、kubectlからは次の様に見えます。 ...

TL;DR ingress-nginxを使用するとオンプレでもIngressを使用出来る MetalLBと組み合わせる Ingress IngressはKubernetes の機能の一つで、L7 LoadBalancerの機能を持ちます。先日紹介した type LoadBalancerは、L4 LoadBalancerで、クラスタ内のDNSで名前解決をし、IP制限などをすることが出来ます。それに対し、Ingressでは、HTTPSの終端となることが出来、ホスト名ベース・パスベースのルーティングを行うことが出来ます。 通常、オンプレでKubernetesを構築した場合、Ingress Controllerと呼ばれる、Ingressを作成する機能が無いためにIngressを使用することが出来ません。 しかし、折角Kubernetesを使用しているのに、ホスト名ベースのルーティングをクラスタ外のロードバランサーに設定するのは面倒です。 どうせならIngress、使いたいですね？ そこで使用できるのがingress-nginx (GitHub: kubernetes/ingress-nginx )です。ingress-nginxはその名のとおり、nginxを使用したIngress Controllerです。Ingressリソースの作成時に、nginxの設定をConfigMapとして保存することでIngressの作成を実現します。 Install MetalLBをインストール している場合、次の二つのコマンドを実行することでインストールできます。 1 2 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml 二行目のコマンドはドキュメント上では docker for macのコマンドとして記載されていますが、type: LoadBalancerが使用できるクラスタ一般で使用できます。 インストールが完了したら、ingress-nginxのサービスにIPアドレスが割当たります。 1 2 3 4 $ kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default-http-backend ClusterIP 10.233.50.56 <none> 80/TCP 2d ingress-nginx LoadBalancer 10.233.47.246 192.168.1.100 80:30431/TCP,443:30017/TCP 2d 実際にブラウザでingress-nginxのIPアドレスにアクセスしてみて、default backend - 404と表示されれば正常に動作しています。 ...

TL;DR MetalLBを使用することでオンプレ(not on OpenStack)に構築したk8sでもtype: LoadBalancerを使用できる type: LoadBalancer kubespray 等を使用して、Kubernetes をオンプレ(on OpenStackを除く)で構築した場合、通常、type: LoadBalancer を使用することができません。これは、type: LoadBalancerは通常CloudProviderにより管理されており、オンプレ(on OpenStackを除く)でk8sを構築した場合にはCloudProvider連携が無いためです。 しかし、k8sを使用するからにはtype: LoadBalancerも使用したいですよね？NodePortなどで代用するにも、ポートがバラバラになってしまって面倒です。 そこで使用できるのがMetalLB (GitHub: google/metallb )です。 MetalLBを使用すると、type LoadBalancerの作成をフックしてアドレス割り当てとアドレスの広報を行ってくれます。 Layer 2 mode MetalLBにはLayer 2 mode(以下L2 mode)とBGP modeがあります。これらのモードはアドレス広報の仕方が違い、L2 modeではARP/NDPで、BGP modeではその名の通りBGPでアドレスの広報を行います。通常、自宅を含むオンプレ環境ではBGPを使用していないと思いますので、L2 modeについて解説します。 L2 modeでは、特定のノードへアクセスを集中させ、kube-proxyによって各サービスへトラフィックを分配します。そのため、実態としてはロードバランサーが実装されている訳ではないことに注意が必要です。単体ノードにアクセスが集中するため、これがボトルネックとなり得ますし、アクセスが集中することになるノードが何らかの理由でアクセスできなくなった場合、フェイルオーバーに10秒程度かかる可能性があります。 requirements & installation 導入は非常に簡単ですが、以下の要件を満たしている必要があります。 他にネットワークロードバランシングの機能が無いKubernetes 1.9.0以降 MetalLB対応表 に記載のあるネットワークで設定されていること これに加え、MetalLBで使用することのできるIPv4アドレスを用意しておく必要があります。 私の環境ではk8sのノードが192.168.1.0/24にあるため、192.168.1.100から192.168.1.159までの60個のアドレスをMetalLB用としました。 要件を満たしていることが確認できたら、MetalLBのインストールを行います。 MetalLBをインストールするには、次のコマンドを実行します。 1 $ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.2/manifests/metallb.yaml Helm を使用してインストールすることもできますが、Chartが最新版ではないので注意しましょう。 次に、次のようなConfigMapを作成します。 1 2 3 4 5 6 7 8 9 10 11 12 apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | address-pools: - name: default protocol: layer2 addresses: - 192.168.1.100-192.168.1.159 これでMetalLBのセットアップは完了です。パブリッククラウドで使用するように、type: LoadBalancerを作成するとアドレスプールからIPアドレスが割り当てられ、アクセスできるようになります。 アドレスプールは複数用意することができ、特定のアドレスプールからIPを割り当てたい場合はtype: LoadBalancerのアノテーションにmetallb.universe.tf/address-pool: <ADDRESS_POOL_NAME>を追加します。 ...