一足遅れて Kubernetes を学び始める - 09. discovery&LB その2 -

ストーリー

前回

一足遅れて Kubernetes を学び始める - 08. discovery&LB その 1 -で Service についての概要を学びました。今回は下記を一気に学びます。

ExternalIP
NodePort
LocadBalancer
Headless
ExternalName
None-Selector
Ingress

※ ClusterIP を飛ばしたのは、前回使った内容で十分だと思ったため。

ExternalIP

こちらは、外向けの IP アドレスを割り振ります。

# sample-externalip.yaml
apiVersion: v1
kind: Service
metadata:
  name: sample-externalip
spec:
  type: ClusterIP
  externalIPs:
    - 192.168.3.33
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 8080
      targetPort: 80
  selector:
    app: sample-app

私の Node 情報では、下記の状態です。

host	ip
raspi001(master)	192.168.3.32
raspi002(worker)	192.168.3.33
raspi003(worker)	192.168.3.34
nfspi(NFS)	192.168.3.35

ここで、spec. externalIPs に、公開したい IP アドレスを上記 Node の IP アドレスより設定します。今回は、１つだけ(raspi002:193.168.3.33)にしました。

# sample-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.12
          ports:
            - containerPort: 80
        - name: redis-container
          image: redis:3.2

前回同様のファイルを用意します。

pi@raspi001:~/tmp $ k apply -f sample-deployment.yaml -f sample-externalip.yaml
pi@raspi001:~/tmp $ k get pod -o=wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE   READINESS GATES
sample-deployment-9dc487867-7n2sz         2/2     Running   0          16m   10.244.1.73   raspi002   <none>           <none>
sample-deployment-9dc487867-nnnqm         2/2     Running   0          16m   10.244.1.74   raspi002   <none>           <none>
sample-deployment-9dc487867-qfdhw         2/2     Running   0          16m   10.244.2.68   raspi003   <none>           <none>
pi@raspi001:~/tmp $ k get service
NAME                TYPE        CLUSTER-IP       EXTERNAL-IP    PORT(S)    AGE
sample-externalip   ClusterIP   10.104.170.220   192.168.3.33   8080/TCP   15m

externalIP が設定されました。

pi@raspi001:~/tmp $ for PODNAME in `k get pods -l app=sample-app -o jsonpath='{.items[*].metadata.name}'`; do k exec -it ${PODNAME} -- cp /etc/hostname /usr/share/nginx/html/index.html; done

どこの pod かどうかわかりやすいくするため、index.html を書き換えます。では、ブラウザからアクセスしてみます。

raspi002 を公開したので、その Node に存在する Pod がランダムに出力されている、つまりロードバランサが動作していることがわかります。

NodePort

ExternalIP のような特定 Node を公開するのと違って、NodePort は、全ての Node を公開します。

試してみます。

# sample-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: sample-nodeport
spec:
  type: NodePort
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 8080
      targetPort: 80
      nodePort: 30080
  selector:
    app: sample-app

pi@raspi001:~/tmp $ k delete -f sample-externalip.yaml #しなくても良い
pi@raspi001:~/tmp $ k apply -f sample-nodeport.yaml
pi@raspi001:~/tmp $ k get service
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
sample-nodeport   NodePort    10.96.173.243   <none>        8080:30080/TCP   66s

内向けには、10.96.173.243:8080 でアクセスでき、外向けには、各 Node の IP アドレス:30080 にアクセスします。どちらも正常にアクセスできています。もちろん、アクセス先の Pod は、ロードバランシングされます。ロードバランシングさせるのが嫌な場合にも対応できます。アクセスされた Node の先は、その Node 内にある Pod のみにアクセスさせる「spec.externalTrafficPolicy：Local」に設定すれば大丈夫です。注意点として、nodePort は、30000~32767 の範囲と決まっています。

LoadBalancer

ExternalIP や NodePort の場合、ロードバランシングするのはクラスタ内の Node になります。そのため、アクセスが集中することで、Node 単一障害が発生しやすいそうです。そこで、LoadBalancer を使うことで、クラスタ外にロードバランサを作成します。

ただ、クラスタ外にロードバランサを作成する際は、プラットフォームによって対応しているか確認が必要です。私のような raspberryPi 環境では、もちろんそういった機能がないため、準備する必要があります。

master(raspi001)に移動

pi@raspi001:~/tmp $ k apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml

metallb と呼ばれるロードバランサを適用します。

https://metallb.universe.tf

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

# l2-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.3.100-192.168.3.200

pi@raspi001:~/tmp $ k apply -f l2-config.yaml

これで、raspberryPi 環境でも loadBalancer が使えます。さっそくつかってみましょう。

# sample-lb.yaml
apiVersion: v1
kind: Service
metadata:
  name: sample-lb
spec:
  type: LoadBalancer
  loadBalancerIP: 192.168.3.100
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 8080
      targetPort: 80
      nodePort: 30082
  selector:
    app: sample-app
  loadBalancerSourceRanges:
    - 192.168.3.0/8

pi@raspi001:~/tmp $ k apply -f sample-deployment.yaml
pi@raspi001:~/tmp $ k apply -f sample-lb.yaml
pi@raspi001:~/tmp $ k get services
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
kubernetes   ClusterIP      10.96.0.1       <none>          443/TCP          16d
sample-lb    LoadBalancer   10.106.253.65   192.168.3.100   8080:30082/TCP   8m4s

お、192.168.3.100:8080 にアクセス可能みたいです。

iMac に移動

~ $ curl -s http://192.168.3.100:8080
<!DOCTYPE html>
...

Headless

今までのロードバランスと違い、公開する IP アドレスは提供されません。 DNS ラウンドロビンによる転送先の Pod の IP アドレスを取得できます。つまり、Headless のサービスへ問い合わせすると、spec.selector で登録した Pod の IP アドレスが手に入ります。 Pod の IP アドレスがほしいときには便利です。（Envoy とか?）

# sample-statefulset-headless.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sample-statefulset-headless
spec:
  serviceName: sample-headless
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.12

# sample-headless.yaml
apiVersion: v1
kind: Service
metadata:
  name: sample-headless
spec:
  type: ClusterIP
  clusterIP: None
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 80
      targetPort: 80
  selector:
    app: sample-app

spec.type が ClusterIP であり、spec.clusterIP が None、そして、metadata.name が statefulset の spec.serviceName と同じことで、Headless Service と呼ぶそうです。

pi@raspi001:~/tmp $ k apply -f sample-statefulset-headless.yaml
pi@raspi001:~/tmp $ k run --image=centos:7 --restart=Never --rm -i testpod  -- dig sample-headless.default.svc.cluster.local
...
;; ANSWER SECTION:
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.1.75
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.2.72
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.2.73
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.1.78
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.1.76
sample-headless.default.svc.cluster.local. 5 IN	A 10.244.2.70

たしかに、headless のサービスに問い合わせると、IP アドレスが返ってきました。

ExternalName

外部のドメイン宛の CNAME を返すサービスです。例えば、Pod から外部のexample.comへアクセスする場合、下記のように設定します。

# sample-externalname.yaml
kind: Service
apiVersion: v1
metadata:
  name: sample-externalname
  namespace: default
spec:
  type: ExternalName
  externalName: example.com

pi@raspi001:~/tmp $ k apply -f sample-externalname.yaml
pi@raspi001:~/tmp $ k run --image=centos:7 --restart=Never --rm -i testpod  -- dig sample-externalname.default.svc.cluster.local
...
;; ANSWER SECTION:
sample-externalname.default.svc.cluster.local. 5 IN CNAME example.com.
example.com.		5	IN	A	93.184.216.34

確かに、sample-externalname.default.svc.cluster.localと問い合わせすることで、外部のexample.comへの CNAME を取得できます。また、外部のサイトを切り替えたいときは、問い合わせ先は変わらずに、sample-externalname.yaml の spec.externalName を変更するだけで済みます。これは切り替えが楽ですね。

None-Selector

外部のサービスに対してロードバランシングします。

# sample-none-selector.yaml
---
kind: Service
apiVersion: v1
metadata:
  name: sample-none-selector
spec:
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
---
kind: Endpoints
apiVersion: v1
metadata:
  name: sample-none-selector
subsets:
  - addresses:
      - ip: 172.217.31.164
      - ip: 172.217.31.165
    ports:
      - protocol: TCP
        port: 80

172.217.31.164 と 172.217.31.165 は、どちらもwww.google.comを指します。

pi@raspi001:~/tmp $ k apply -f sample-none-selector.yaml
pi@raspi001:~/tmp $ k get service
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
sample-none-selector   ClusterIP      10.102.225.99   <none>          8080/TCP         88s
pi@raspi001:~/tmp $ k describe svc sample-none-selector
Name:              sample-none-selector
...
Type:              ClusterIP
IP:                10.102.225.99
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         172.217.31.164:80,172.217.31.165:80
...

ClusterIP なので、内部で公開されていますね。

pi@raspi001:~/tmp $ curl 10.102.225.99:8080
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com:8080/">here</A>.
</BODY></HTML>
...

少し結果が不自然だったのですが、確かに google.com へアクセスしました。外部サービスへのロードバランシングも容易に実現できます。

※ 172.217.31.164へアクセスすると、リダイレクトがかかります。Status Code: 301

Ingress

今までのロードバランサは、l4 レイヤーのロードバランサです。(IP アドレスとポート番号による負荷分散) Ingress では、l7 レイヤーのロードバランサを提供します。(URL や HTTP ヘッダーで負荷分散が可能)

Ingress を置く場所は、クラスタ内、外の２つあります。クラスタ外の場合は、使うプラットフォームによります。クラスタ内の場合は、Nginx Ingress を使うことができます。

raspberryPi 環境では、Ingress-Nginx-Controller を使うことで、Ingress を使えるそうです。 NGINX Ingress Controller - Installation Guide を参考にして進めたのですが、arm64 環境では動きませんでした。

そこで、下記の yaml を発見し、試してみると動作します。ぜひ、お試しあれ。 hectcastro/mandatory.yaml

※ namespace を削除できない場合は、こちらを参考下さい。

お片付け

pi@raspi001:~/tmp $ k delete -f sample-externalip.yaml -f sample-deployment.yaml -f sample-nodeport.yaml -f sample-lb.yaml -f sample-statefulset-headless.yaml -f sample-headless.yaml -f sample-none-selector.yaml -f sample-externalname.yaml

最後に

Service について学びました。様々な用途に応じて、エンドポイントを公開する手段を学びました。手を動かして確認してみると、理解が深まりました。本番で k8s を使った経験はありませんが、今後必要に迫られた際に、こちらの記事を思い返そうと思います。

次回はこちらです。