Day14，来试试OpenELB

正文

前面几个章节有提到Service type LoadBalancer，这个service type在云端上依赖cloud vendor的loadbalancer得以实作，而在地端想要有同样的功能体验则大致上有两种做法，第一种是透过硬体Loadbalancer串接，且有提供Kubernetes custom controller/CRD之类的厂商(ex. F5 BIG-IP)，而另一种则是透过software实作，达成类似情境。

而我们这里能选择就只有後者这种方式(没有前者的机器)，过去提到这一块最着名的莫过於MetalLB，也是我工作上常选择的。但前阵子因缘际会参与了一场线上的meetup，内容是介绍kubesphere的架构，kubesphere内的NLB选择为OpenELB(PorterLB)，这也让我心里想着改天也得来试玩看看。

进行安装

kubectl apply -f https://raw.githubusercontent.com/kubesphere/porter/master/deploy/porter.yaml

确认porter-system namespace下，有两个completed、一个running

当节点存在复数网卡时，需定义Annotation的网卡IP。(单一网卡则不用)

kubectl annotate nodes vm01 layer2.porter.kubesphere.io/v1alpha1="192.168.1.231"
kubectl annotate nodes vm02 layer2.porter.kubesphere.io/v1alpha1="192.168.1.232"
kubectl annotate nodes vm03 layer2.porter.kubesphere.io/v1alpha1="192.168.1.233"
kubectl annotate nodes vm04 layer2.porter.kubesphere.io/v1alpha1="192.168.1.234"
kubectl annotate nodes vm05 layer2.porter.kubesphere.io/v1alpha1="192.168.1.235"

布署layer2的设定，与IP Pools。

kubectl apply -f porter-layer2-eip.yaml

apiVersion: network.kubesphere.io/v1alpha2
kind: Eip
metadata:
  name: porter-layer2-eip
spec:
  address: 192.168.1.240-192.168.1.250
  interface: ens34 ##对应server上网卡
  protocol: layer2

快速布署一个测试用的Nginx

kubectl create ns test
kubectl apply -f test-nginx.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: test
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: test-nginx-svc
  namespace: test
  annotations:
    lb.kubesphere.io/v1alpha1: porter
    protocol.porter.kubesphere.io/v1alpha1: layer2
    eip.porter.kubesphere.io/v1alpha2: porter-layer2-eip
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: 80
  externalTrafficPolicy: Cluster

我们这边设定的externalTrafficPolicy: Cluster，特性上是不会保留Client IP的。
incomming request会进入任一worker节点，透过cluster(kube-proxy转发至对应pod)

观察一下service确认我们拿到了192.168.1.240的ip

打开浏览器检查一下，服务正常

检查一下log，发现来源IP为10.233系列的，为Cluster内的IP，如预期没有留存到Client IP。

在笔电上试着PING看看192.168.1.240，会发现是由192.168.1.234(vm04)回应

而我们的nginx则是在192.168.1.235(vm05)上。

再次将service移除、并重新添加并修改规则为externalTrafficPolicy: local这是能够保留client IP的方式(实务上我们很多情境皆会要求保留来源IP)，因为这个规则不会透过kube-proxy转发，而是直接流向host pod，也就是说incomming request会流入能够回应的pod的节点(这里指的就是nginx所在节点)。

布署完後一样是取得192.168.1.240的IP，使用ping呼叫，发现就是由192.168.1.235(vm05进行回传)，与预期一致。

检查nginx log，确认可以看到log真正的client ip(192.168.1.134)了

明天就可以来用用ingress controller将服务正式hosting起来了。

闲聊

官网有强调要打开kube-proxy IPVS strict ARP，这个部分倒是与MetalLB一致，但我这次用的是iptables，所以不管好像也没差。初步看起来的感觉是openELB应该是更lightweight的选择(虽然我认为MetalLB也是十分轻巧、设定简单)，不过都还用的很少需要再观察观察~