Kubernetes Ingress Controller 高可靠部署最佳实践

背景简介

在Kubernetes集群中,Ingress是授权入站连接到达集群服务的规则集合,为您提供七层负载均衡能力,您可以通过 Ingress 配置提供外部可访问的 URL、负载均衡、SSL、基于名称的虚拟主机等。作为集群流量接入层,Ingress Controller的高可用性显得尤为重要,今天我们主要探讨如何部署一套高性能高可靠的Ingress Controller接入层。

高可用部署架构

高可用性首先要解决的就是单点故障问题,一般常用的是采用多副本部署的方式,我们在Kubernetes集群中部署高可用Ingress Controller接入层同样采用多节点部署架构,同时由于Ingress作为集群流量接入口,建议采用独占Ingress节点的方式,以避免业务应用与Ingress服务发生资源争抢。
Kubernetes Ingress Controller 高可靠部署最佳实践
如上述部署架构图,由多个独占Ingress实例组成统一接入层承载集群入口流量,同时可依据后端业务流量水平扩缩容Ingress节点。当然如果您前期的集群规模并不大,也可以采用将Ingress服务与业务应用混部的方式,但建议进行资源限制和隔离。

在阿里云容器服务集群中部署高可用Ingress接入层

当我们通过阿里云容器服务控制台成功申请一个Kubernetes集群后,默认集群内部已经部署了一套拥有2个Pod副本的Nginx Ingress Controller服务,其前端挂载在一个公网SLB实例上,通过如下命令可以查看到:

  ~ # 1> 查看nginx-ingress-controller pod副本
  ~ kubectl -n kube-system get pod | grep nginx-ingress-controller
nginx-ingress-controller-674c96ffbc-7h4nt                    1/1       Running   0          4h
nginx-ingress-controller-674c96ffbc-rvfcw                    1/1       Running   0          4h
  ~
  ~
  ~ # 2> 查看nginx-ingress-lb服务对应的公网SLB IP
  ~ kubectl -n kube-system get svc nginx-ingress-lb
NAME               TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE
nginx-ingress-lb   LoadBalancer   172.19.6.38   47.96.222.140   80:30990/TCP,443:30076/TCP   4h

随着集群业务规模的逐渐扩大,我们需要同时扩容Ingress接入层以保证集群接入层的高性能高可用,因此我们通过如下几种方式来完成:

1、调整Replica数量

我们可以通过简单地调整Nginx Ingress Controller Deployment的Replica数量来快速扩缩容Ingress接入层规模:

  ~ # 1> 这里通过scale命令来扩容到3个Pod副本(可依据具体业务流量来设置为合适的值)
  ~ kubectl -n kube-system scale --replicas=3 deployment/nginx-ingress-controller
deployment.extensions "nginx-ingress-controller" scaled
  ~ 
  ~
  ~ # 2> 查看当前Pod副本情况
  ~ kubectl -n kube-system get pod | grep nginx-ingress-controller
nginx-ingress-controller-674c96ffbc-7h4nt                    1/1       Running   0          4h
nginx-ingress-controller-674c96ffbc-rvfcw                    1/1       Running   0          4h
nginx-ingress-controller-674c96ffbc-xm8dw                    1/1       Running   0          12s

2、指定节点部署

我们知道,负载均衡软件是一种高计算型和高网络IO型的资源,通常情况下建议选择高主频高网络IO的机器来部署,因此当我们集群中同时存在不同规格的节点实例时,假若我们希望将Nginx Ingress Controller仅仅运行在指定的一些高配置的节点上,我们可以通过节点打标的方式来完成:

  ~ # 1> 查看当前集群节点情况
  ~ kubectl get node
NAME                                 STATUS    ROLES     AGE       VERSION
cn-hangzhou.i-bp109znbuf1b19ik17i2   Ready     <none>    4h        v1.11.2
cn-hangzhou.i-bp109znbuf1b19ik17i3   Ready     <none>    4h        v1.11.2
cn-hangzhou.i-bp109znbuf1b19ik17i4   Ready     <none>    4h        v1.11.2
cn-hangzhou.i-bp14p7rlsw8mc28w5wof   Ready     master    4h        v1.11.2
cn-hangzhou.i-bp1845cet96qo07msekf   Ready     master    4h        v1.11.2
cn-hangzhou.i-bp19420uhlyv2e5k4kmh   Ready     master    4h        v1.11.2
  ~
  ~
  ~ # 2> 若我们希望部署在cn-hangzhou.i-bp109znbuf1b19ik17i3和cn-hangzhou.i-bp109znbuf1b19ik17i4两个节点上,
  ~ #    我们可以先给这两个节点打上标 node-role.kubernetes.io/ingress="true"
  ~ kubectl label nodes cn-hangzhou.i-bp109znbuf1b19ik17i3 node-role.kubernetes.io/ingress="true"
node "cn-hangzhou.i-bp109znbuf1b19ik17i3" labeled
  ~ kubectl label nodes cn-hangzhou.i-bp109znbuf1b19ik17i4 node-role.kubernetes.io/ingress="true"
node "cn-hangzhou.i-bp109znbuf1b19ik17i4" labeled
  ~
  ~
  ~ # 3> 然后我们更新deployment增加nodeSelector配置
  ~ kubectl -n kube-system patch deployment nginx-ingress-controller -p '{"spec": {"template": {"spec": {"nodeSelector": {"node-role.kubernetes.io/ingress": "true"}}}}}'
deployment.extensions "nginx-ingress-controller" patched
  ~
  ~
  ~ # 4> 最后我们查看Pod部署情况,发现已经部署在指定的两个节点上
  ~ kubectl -n kube-system get pod -o wide | grep nginx-ingress-controller
nginx-ingress-controller-7cc9b5956c-fs8kf                    1/1       Running   0          50s       172.16.2.4      cn-hangzhou.i-bp109znbuf1b19ik17i4
nginx-ingress-controller-7cc9b5956c-xd77k                    1/1       Running   0          1m        172.16.2.131    cn-hangzhou.i-bp109znbuf1b19ik17i3

注意:1)确保打标节点数不少于Pod副本数以尽量规避多个Pod运行在同一个节点上;2)不建议部署到master节点上;

全方位监控

集群Ingress接入层的监控是必不可少的,您可以通过阿里云容器服务监控以及阿里云云监控对Ingress Pod和Ingress Node进行全方位监控。

上一篇:2018云栖Workshop应用发布实践手册(二)


下一篇:如何真实压测一个Web浏览型应用的性能