外部サービスをIngress backendとして使用する

TL;DR Service type: ExternalNameを使用する External Service Kubernetes では、<code>Ingress</code> を使用することで、ホスト名ベースのロードバランシング/リバースプロキシを行うことが出来ます。その際、プロキシ先としてKubernetes上の<code>Service</code> を指定するのですが、場合によってはKubernetesクラスタ外のサービスをプロキシ先としたい場合があります。例えば、弊宅の環境では、次の様にプロキシしています。 基盤であるOpenNebulaのダッシュボード以外は*.web-apps.techとして、Kubernetesへとルーティングしています。 ところで、本ブログは現在Kubernetes上へ移行作業中です。今のところはまだ、Kubernetes上へ載せていません。しかし、折角プロキシの設定が減っているので、blog.web-apps.techもIngressリソースとして管理したいです。 そこで使用できるのがService type: ExternalNameです。ExternalNameとして外部サービスを登録することで、Ingressのバックエンドとして使用できるようになります。 設定 設定はごく簡単で、次の様にします。 --- 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からは次の様に見えます。 $ kubectl get svc --name external-services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ghost ExternalName <none> 192.168.1.41 <none> 54m 後は、普通にIngressの設定をするだけです。 --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ghost namespace: external-services spec: rules: - host: blog....

2018-08-07 · nasa9084

ingress-nginxを使用してオンプレでもIngressを使用する

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をインストール している場合、次の二つのコマンドを実行することでインストールできます。 $ 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アドレスが割当たります。 $ 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と表示されれば正常に動作しています。 ルーターからKubernetes上のサービスに直通で問題ない(IngressでHTTPS終端なども行う)場合、ルーターのNAT/NAPT設定で、80/443番ポートの行き先をこのIPアドレスとします。 クラスタ外のLAN内に別のサービスも存在し、別途ロードバランサーなどで振り分けを行っている場合、ワイルドカードを使用してこのIPアドレスへ振り分けるのがお勧めです(nginxでは、ワイルドカードより、正確にマッチした方のルールを優先するため、設定されていない場合にKubernetesへトラフィックが流れることとなります)。 弊宅では、ルーターから80/443でアクセスされるnginxに次の様に設定しています。 server { listen 80; server_name *....

2018-08-06 · nasa9084

Let's Encryptでワイルドカード証明書を取得する

先日twitterでサポートされたと発表されたLet’s Encryptのワイルドカード証明書ですが、本日未明、正式にcertbotがワイルドカード証明書に対応したと発表されました !1 早速ですが、実際にワイルドカード証明書を取得してみます。 尚、今回対象とした環境は以下のとおりです。 CentOS 7 リバースプロキシとしてnginx DNSはGehirn DNS では、作業していきます。 CentOS 7でcertbotを使用する場合、大抵はyumでcertbotをインストールしていると思いますので、まずはアップデートします。 $ sudo yum update 出力は省略しますが、certbotが0.22.0にアップデートされます。 0.22.0はワイルドカード対応バージョンですので、問題ないですね! 公式のマニュアルでは、dns-pluginを使うよう書いてあり ますが、Gehirn DNSのプラグインは無いため、今回は手動で行きます。 以下のコマンドを実行します。 # certbot certonly --manual --preferred-challenges dns -d *.web-apps.tech --server https://acme-v02.api.letsencrypt.org/directory Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator manual, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): nasa.9084.bassclarinet@gmail.com Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org ------------------------------------------------------------------------------- Please read the Terms of Service at https://letsencrypt....

2018-03-13 · nasa9084

二重にプロキシされたRancher Serverのリバースプロキシ設定

常時SSLの環境で二重にリバースプロキシされた環境のRancherは、公式ドキュメント通りの設定を行っても正常に動作しません。 X-Forwarded-ProtoがHTTPSの状態でRancher Serverまで届くように設定することで問題を解消できます。

2017-09-04 · nasa9084

Rancher-HAProxyでHSTSを設定する

HSTSはHTTP Strict Transport Securityの略で、HTTPでの接続を強制的にHTTPSへと変更するようウェブブラウザへ伝達するセキュリティ機構です。 Rancher-HAProxyでロードバランシングしている場合にもHSTSを使えるように設定してみました。

2017-09-02 · nasa9084