#AWS最初からKubernetesやGKEを使っているプロジェクトには無縁だと思うのだが、途中から部分的にKubernetes化を進めて、Kubernetesクラスタ外からServiceを利用できるようにしたいというケースもあるかと思う。ControllerこのようなケースではserviceをKubernetesクラスタ外に公開する必要があるので、ingressを用意する必要がある。ingressから受けたリクエストをうまくルーティングする層が必要になるわけだが、その際に役に立つのがingress-nginxだ。設定kube-systemに配置しているが、別のnamespaceでingressを設定すればクロスネームスペースからでも利用できる。この辺は各自の環境に合わせて忖度してほしい。default-backenddefault-backendはingressで設定してないルール外へのリクエストを受けるためのバックエンド。ingress-nginxはこれを利用するのでまずはdefault-backendをserviceとして用意しておく。TCP---configmapingress-nginxにしかけるconfigmap。nginxのバックエンドにupstreamされる際のログのフォーマットが設定できる。"true"を設定するが、今回のようにinternalで素のHTTP/1.1であればナシでいい。}'deployment続いてdeployment。ingress-nginxコンテナを配置する。ingress-nginxを複数配置したいようなケースも当然あるので、Kubernetesのingressが利用するingress-nginxを特定できるようにオプションで--ingress-classを設定しておき、任意の名前をつけておくとよい。--ingress-class=nginx-internalserviceServiceのAnnotationとしてservice.beta.kubernetes.io/aws-load-balancer-internalを設定している。ELBが自動で作成される。セキュリティグループも新規作成したELB用に新たに作られるので、適切なACLを設定してほしい。httpingress最後に任意のnamespace上に、ingress-nginxを利用して個別のserviceにVirtualHost的なプロキシをするためのingressを用意する。deploymentで--ingress-classを指定しているので、この値をkubernetes.io/ingress.classのアノテーションで設定しておく。80こうしておくと、hogehoge.your_internal.localへのHTTPリクエストはhogehogeというサービスにプロキシされるようになる。個別のnamespaceにそれぞれingress-nginxを立てるよりは、どこか一箇所に集約し、ELBを1本でも節約できる方向に持っていった方がよいと思う。ちなみにここに定義したからといってRoute53に設定DNSが定義されるわけではないので注意。これは各々の運用によると思うが、kubernetes-incubator/external-dnsを利用するのも良いだろう。