一只安静的猫

理解service的角度

这篇文章不是关于如何使用kubernetes中的service，而是尝试整理我自己对service的看法，然后加深对service的理解。那么，我是从哪几个角度去看待service呢？

• service是服务的稳定性保证
• service是集群中的load balance
• 通过无selector的service去理解VIP(虚拟ip)
• service的设计，和不同实现方式的性能

service是服务的稳定性保证

在k8s集群中，无状态的pod副本是可以随时删除、随时创建的，并且重新创建的pod不再保留旧的pod的任何信息，包括ip地址。在这样的情况下，前端应用如何使用后端的这些pod来提供服务就成了问题，因此k8s实现了service这样一个抽象的概念。对于有selector的service，它在被创建的时候会自动创建endpoint资源，这个endpoint中包含了所有的pod的ip和端口，并且在之后的pod的删除、创建中，这个endpoint中会立即更新相关pod的ip和端口信息。同时，service的ip地址是永远固定的，service和endpoint是一一对应的关系。这样，如果前端应用通过固定的service ip来访问pod提供的服务，那么就可以在endpoint中找到一个可用的pod的ip和端口，然后通过一些操作（这个在后面会整理）将数据包转发到指定的pod上即可。

# 你可以通过kubectl查看service和endpoint来加深理解

kubectl -n h2o describe svc h2o

Name:              h2o
Namespace:         h2o
Labels:            app=h2o
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"h2o"},"name":"h2o","namespace":"h2o"},"spec":{"clusterIP...
Selector:          app=h2o
Type:              ClusterIP
IP:                None
Port:              web  54321/TCP
TargetPort:        54321/TCP
Endpoints:         10.42.1.33:54321,10.42.2.139:54321
Session Affinity:  None
Events:            <none> kubectl -n h2o get endpoints h2o
NAME   ENDPOINTS                            AGE
h2o    10.42.1.33:54321,10.42.2.139:54321   4h45m

service通过ip地址的固定来保证服务的稳定性。那为啥service就是可以固定不变的呢？这是因为service本身就是一个抽象的概念啊，它不是一个正在运行的进程，只是一条数据，也正因为如此，它的ip地址和端口号也是不存在的，这些都是存储在etcd中的一条数据。那么k8s是如何通过这样一个虚假的ip和端口将请求转发到真实存在的pod中呢？这就是后面要说的内容了。

service是集群中的load balance

在上一节说到，一个service会对应一个endpoint，这个endpoint中会保存所有当前匹配到的pod的ip和端口号。那么现在有一个http请求过来了，发现endpoint中有三个待选的pod，那么我们使用一定的方式比较公平的选择出一个pod，就轻松的达到了负载均衡的效果。

那么k8s中，load balance的策略是什么样的呢？因为不同的service实现方式使用的方法不同，这个内容会在后面整理。

通过无selector的service去理解VIP(虚拟ip)

在前面的内容中，service一直和endpoint、pod关联在一起，那么如果我们的service没有selector，就不会创建endpoint了，也不会关联pod。前面也提到了service是一个抽象的概念，其拥有的ip和port都是假的。其实这个叫做VIP(virtual ip)。那么，如何通过无selector的service来理解VIP呢？

在k8s中创建无selector service的时候，不会自动创建关联的endpoint，更不会去匹配pod了。但是这样的service仍然是拥有ip和port的。我们可以尝试一下：

svc-without-selector.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081

kubectl apply -f svc-without-selector.yaml

查看一下这个svc的详情:

$ kubectl describe svc my-service

Name:              my-service
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-service","namespace":"default"},"spec":{"ports":[{"port":8081,...
Selector:          <none>
Type:              ClusterIP
IP:                10.43.12.208
Port:              <unset>  8081/TCP
TargetPort:        8081/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

除了拥有ip和端口号，就什么都没有了。这就是说service为什么就是一条数据的原因，10.43.12.208也就是一个VIP。

对于无selector的service还有一个用处，就是让集群内部的应用可以稳定的访问到集群外部的服务。因为service是稳定的，那么集群内部都可以访问这个service，然后让这个service将请求转发到集群外。

这里我们可以手动创建一个endpoint，这个endpoint包含了集群外的两个http服务

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.168.50.99
      - ip: 192.168.50.201
    ports:
      - port: 8081

然后我们先检查一下service，发现endpoints已经更新了。

$ kubectl describe svc my-service

Name:              my-service
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-service","namespace":"default"},"spec":{"ports":[{"port":8081,...
Selector:          <none>
Type:              ClusterIP
IP:                10.43.12.208
Port:              <unset>  8081/TCP
TargetPort:        8081/TCP
Endpoints:         192.168.50.201:8081,192.168.50.99:8081
Session Affinity:  None
Events:            <none>

我们在集群内部访问一下(使用kubectl exec到一个pod上):

$ wget my-service:8081 -q -O out | cat out
server 2
$ wget my-service:8081 -q -O out | cat out
server 1
$ wget my-service:8081 -q -O out | cat out
server 2
$ wget my-service:8081 -q -O out | cat out
server 1

service的设计，和不同实现方式的性能

service的设计是以提高性能为前提不断的演进的，这里是关于Service的设计讨论: DESIGN: Services v2。感兴趣的还可以看看k8s-release-v1.0的时候对service的描述: Service

service的设计中有4个角色: Pod、 Service、Ambassador、Portal

• Pod: k8s集群中的最小调度单位，包含一个或多个容器
• Service: 一组pod的集合，由标签选择器来关联
• Ambassador: 中文翻译是大使，是一段可执行的逻辑，它负责实现客户端访问Service，然后将请求转发到一个对应的Pod上。这个Ambassador可以是一个云服务商的服务，也可以是一个单独的pod(比如haproxy)，或者是每个节点都有的共享进程(kube-proxy)。
• Portal: 固定的ip:port对，客户端只要访问这个Portal，请求自然会被转发到Ambassador上，客户端不需要理解Ambassador的具体实现。

最初的设计中是有三种方案，

方案一: 每个服务一个ip，共享的Ambassador。这个ip就是上面说的Portal ip。将服务以及ip、端口广播给所有的kube-proxy实例。kube-proxy设置好iptables来“窃取”所有到Portal(ip,port)的请求，然后将这个请求转发到自己的某个端口上。这里kube-proxy扮演的是Ambassador角色，它会使用round-robin的方法来把请求均衡的分发到Service后面的Pod上。这个方案里，有以下的优点和缺点：

优点：
– 不会有端口冲突
– Service的ip和port都是固定的，方便做DNS A (forward) 和 PTR (reverse)和 SRV 记录。
– iptables可以放在root namespace，即使pods重启了也不需要更新iptables(这是因为iptables是负责将到service ip:port的流量转发到kube-proxy的一个端口上即可)。
– 不需要在pod上预先声明需要的Service。

缺点：

• kube-proxy是多租户的(需要为所有的service做流量转发)
• 从kube-proxy转发的流量的源ip不是真实的源ip，
• 需要为portal预留虚拟ip空间
• 需要master跟踪和检查所有的portal ip
• 当service数量级上千后可扩展性不高

方案二： 每个服务一个ip，私有的Ambassador。对每个pod来说，都有一个私有的的ambassador，这要求pod需要先声明它们想先访问那个服务（否则的话，对于集群中的每次Service的添加和删除，都需要kubelet或其他的root-namespace、true-root的用户代理变动到每个pod的namespace下。[iptables规则需要root用户])，这样才能在pod的命名空间下建立iptables规则。

优点:

• 不会有端口冲突
• Service的ip和port都是固定的，方便做DNS A (forward) 和 PTR (reverse)和 SRV 记录。
• 代理不是多租户的
• 从kube-proxy转发的流量的源ip是真实的源ip，
• 容易从方案一迁移
• 需要pod预先声明服务（结构良好)

缺点:

• iptables是配置在pod的namespace下，但是pod的命名空间重启了就必须重新运行一次
• 需要为portal预留虚拟ip空间
• 需要master跟踪和检查所有的portal ip
• 需要pod预先声明服务（目前还没实现）

方案三：localhost的portal，私有的ambassador

不同于给service分配ip，而是使用本地的端口号作为portal。

介绍完这三种方案后，就可以引入service最终的演进了: userspace->iptables->ipvs。

这里先放一张iptables的工作流程图，方便理解：

userspace模式

这里的userspace就是方案一的实现，在k8s 1.0的发布中正式启用。userspace的工作原理图如下：

这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。 任何连接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的某个上面（如 Endpoints 所报告的一样）。 使用哪个 backend Pod，是 kube-proxy 基于 SessionAffinity 来确定的。

最后，它安装 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到 backend Pod。默认情况下，用户空间模式下的kube-proxy通过round-robin选择后端。

这里有一个问题在于，client访问service的clusterIP时，iptables会把流量转发到kube-proxy的某个端口上，这样的话，每次转发都有一个内核态到用户态的转换。

iptables模式

这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会安装 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。 对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend 组合。

默认的策略是，kube-proxy 在 iptables 模式下随机选择一个 backend。类似于这样

iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。

如果 kube-proxy 在 iptable s模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。

您可以使用 Pod readiness 探测器 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。 这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。

ipvs模式

ipvs是在Kubernetes v1.11正式可用的。ipvs也是依赖于iptables的，但是它的性能更高。

在ipvs模式下，kube-proxy监视Kubernetes服务和端点，调用netlink接口相应地创建IPVS规则，并定期将IPVS规则与Kubernetes服务和端点同步。该控制循环可确保IPVS状态与所需状态匹配。访问服务时，IPVS　将流量定向到后端Pod之一。

IPVS代理模式基于类似于iptables模式的netfilter挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。 这意味着，与iptables模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

IPVS提供了更多选项来平衡后端Pod的流量。 这些是：

• rr: round-robin
• lc: least connection (smallest number of open connections)
• dh: destination hashing
• sh: source hashing
• sed: shortest expected delay
• nq: never queue

注意：
要在IPVS模式下运行kube-proxy，必须在启动kube-proxy之前使IPVS Linux在节点上可用。

当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。

ipvs在同步规则、网络带宽、cpu/内存消耗上都明显优于iptables，关于具体的性能数据可以看这篇文章: 华为云在 K8S 大规模场景下的 Service 性能优化实践。ipvs的详细介绍可以看这篇文章:ipvs 基本介绍。ipvs和iptables的对比:kube-proxy 模式对比：iptables 还是 IPVS？

安装

cfssl是基于go的，因此需要安装go

go get -u github.com/cloudflare/cfssl/cmd/cfssl
go get -u github.com/cloudflare/cfssl/cmd/cfssljson

安装完成后如果不能直接使用cfssl请检查$GOPATH/bin是否加入到PATH环境变量中。

执行cfssl查看一下cfssl提供的命令

Usage:
Available commands:
        sign
        serve
        gencsr
        ocspsign
        ocspserve
        revoke
        certinfo
        version
        crl
        gencert
        ocsprefresh
        scan
        info
        print-defaults
        bundle
        genkey
        gencrl
        ocspdump
        selfsign
Top-level flags:

创建CA

CA的全称是Certificate Authority，也叫证书授权中心。CA的作用是作为一个权威的、被信任的第三方机构，提供管理和签发证书。在使用https访问一个网站时，为了证明这个网站是可信任的，那么就需要使用CA颁发的证书来证明自己。

因为在内网环境中搭建docker-registry，必然不可能用到互联网上的CA机构，因此我们需要自己扮演这个角色。首先创建文件夹

mkdir ca
cfssl print-defaults config > ca/ca-config.json
cfssl print-defaults csr > ca/ca-csr.json

然后修改ca-config.json

{
    "signing": {
        "default": {
            "expiry": "2540400h"
        },
        "profiles": {
            "www": {
                "expiry": "2540400h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth"
                ]
            },
            "client": {
                "expiry": "2540400h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            }
        }
    }
}

生成ca

cfssl gencert -initca ca/ca-csr.json | cfssljson -bare ca/ca -

生成服务器证书

mkdir server
cfssl print-defaults csr > server/server.json

修改server.json

{
    "CN": "docker-registry",
    "hosts": [
        "docker-registry.k8s",
        "www.docker-registry.k8s"
    ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "ST": "SH",
            "L": "Shanghai"
        }
    ]
}

签发证书

cfssl gencert -ca=ca/ca.pem -ca-key=ca/ca-key.pem -config=ca/ca-config.json -profile=www server/server.json | cfssljson -bare server/server

使用

上面两步得到了ca.pem, server-key.pem, server.pem。ca.pem是ca的证书，server-key.pem是服务器证书的私钥，server.pem是服务器证书

为了在k8s中使用，我们需要先创建默认的tls secret

kubectl -n docker-registry create secret tls docker-registry-tls-cert --key=server/server-key.pem --cert=server/server.pem

为电脑导入ca证书

sudo mkdir /usr/share/ca-certificates/extra
sudo cp ca.pem /usr/share/ca-certificates/extra/ca.crt

运行命令更新证书

sudo dpkg-reconfigure ca-certificates

然后使用curl查看ca根证书是否安装成功

curl -v https://docker-registry.k8s

显示一下内容表示成功

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CN; ST=SH; L=SH; CN=DR
*  start date: Jun 26 06:37:00 2019 GMT
*  expire date: Apr 17 06:37:00 2309 GMT
*  subjectAltName: host "docker-registry.k8s" matched cert's "docker-registry.k8s"
*  issuer: C=US; ST=CA; L=San Francisco; CN=example.net
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: docker-registry.k8s
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.15.9
< Date: Wed, 26 Jun 2019 11:40:04 GMT
< Content-Length: 0
< Connection: keep-alive
< Cache-Control: no-cache
< 
* Connection #0 to host docker-registry.k8s left intact

这里有一点需要注意的，我的电脑上安装了anaconda的环境，因此curl是在anaconda下的curl，它会默认加载/home/username/anaconda3/certs/cacert.pem这个。因此我需要将/etc/ssl/certs/ca-certificates.crt覆盖掉这个文件才能默认加载。或者也可以使用--cacert指定根目录文件的位置。

或者可以参考这篇详细的说明： https://jite.eu/2019/2/6/ca-with-cfssl/#

chrome下的相关设置

即使在我将根证书设置好并且验证成功，但是chrome仍然会有不安全的标识，这是因为需要为chrome单独导入根证书，设置的路径为: 设置 -> 高级 -> HTTPS相关设置。