kubernetes不可以不知道的操作我爱编程

高阶k8s HA 集群搭建(二)

2018-07-26  本文已影响32人  我的橙子很甜

介绍

在上一期HA k8s搭建介绍有说到,目前有两种比较火的HA集群,那么今天我们来说说第二种,也是目前比较主流的部署方式,采用的是haproxy+keepalived+etcd+k8s的模式,和第一种集群相比较多了有个haproxy,它是干嘛的呢,下面是它的大概简介

HAProxy简介

(1)HAProxy 是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上,完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。

(2)HAProxy 实现了一种事件驱动、单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

(3)HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的,有时我们很需要限制攻击蠕虫(attack bots),也就是说限制它们的连接打开从而限制它们的危害。 这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救

了很多站点,这个优点也是其它负载均衡器没有的。

(4)HAProxy 支持全透明代理(已具备硬件防火墙的典型特点): 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。

性能

HAProxy借助于OS上几种常见的技术来实现性能的最大化。

1,单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。

2,O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测。

3,在任何可用的情况下,单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存带宽;

4,借助于Linux 2.6 (>= 2.6.27.19)上的splice()系统调用,HAProxy可以实现零复制转发(Zero-copy forwarding),在Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting);

5,内存分配器在固定大小的内存池中可实现即时内存分配,这能够显著减少创建一个会话的时长;

6,树型存储:侧重于使用作者多年前开发的弹性二叉树,实现了以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列;

7,优化的HTTP首部分析:优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域;

8,精心地降低了昂贵的系统调用,大部分工作都在用户空间完成,如时间读取、缓冲聚合及文件描述符的启用和禁用等;

所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载,甚至于在非常高的负载场景中,5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象,这意味着HAProxy进程消耗比系统空间消耗低20倍以上。因此,对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍,其CPU占用率也仅为10%,这也解释了为何7层处理对性能影响有限这一现象。由此,在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。

在生产环境中,在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障故障时的紧急解决方案也时长可见。硬件负载均衡设备在“报文”级别处理请求,这在支持跨报文请求(request across multiple packets)有着较高的难度,并且它们不缓冲任何数据,因此有着较长的响应时间。对应地,软件负载均衡设备使用TCP缓冲,可建立极长的请求,且有着较大的响应时间。

                                                                        摘抄至HAProxy用法详解 全网最详细中文文档


一般情况下haproxy会和keepalived一起使用。

老规矩,下面附上k8s理想的高可用架构图。

k8s 理想HA高可用

那在本文中,我们的k8s架构应该是怎么样的呢,我从网上找到了一个非常符合我们整个K8S HA架构的图,然后稍微做了修改。本文大致高可用架构图如下

本文高可用集群架构图

在原图中使用的是Nginx作为负载均衡,而我们本文中则使用的是haproxy。好了下面开始目前主流的k8s架构搭建

主机节点清单

主机名IP地址说明组件,如果是没搭建过k8s集群的,需要先看看我之前写的初阶k8s集群搭建,需要安装的一些软件和容器镜像。

master1节点 192.168.100.1 4核4G内存 

keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster

master2节点 192.168.100.2  4核4G内存 

keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster

master3节点 192.168.100.3 4核4G内存 

keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster

vip 192.168.100.4 keepalived 4核4G内存 

在每个master节点上设置好hostname 、hosts

192.168.100.1 master1

192.168.100.2 master2

192.168.100.3 master3

由于本次安装全部容器化部署,因此部署过程相对比较简单。

ECTD部署

在每个master节点上

先拉取最新的etcd官方镜像,这可能需要翻墙,童鞋们可以改下阿里云的加速镜像地址,这里就不做多概述了,官方最新的etcd镜像版本对应常规版的etcd是3.2.17版本

docker pull quay.io/coreos/etcd

docker tag quay.io/coreos/etcd quay.io/coreos/etcd:3.2.17

新建一个etcd数据存储路径,下面只是例子,童鞋们自行修改

mkdir /u03/etcd_docker 


master1

docker run -d \

--restart always \

-v /etc/etcd/ssl/certs:/etc/ssl/certs \

-v /u03/etcd_docker:/var/lib/etcd \

-p 2380:2380 \

-p 2379:2379 \

--name etcd \

quay.io/coreos/etcd:3.2.17 \

etcd --name=master1 \

--advertise-client-urls=http://192.168.100.1:2379 \

--listen-client-urls=http://0.0.0.0:2379 \

--initial-advertise-peer-urls=http://192.168.100.1:2380 \

--listen-peer-urls=http://0.0.0.0:2380 \

--initial-cluster-token=etcd-cluster-0 \

--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \

--initial-cluster-state=new \

--auto-tls \

--peer-auto-tls \

--data-dir=/var/lib/etcd

master2

docker run -d \

--restart always \

-v /etc/etcd/ssl/certs:/etc/ssl/certs \

-v /u03/etcd_docker:/var/lib/etcd \

-p 2380:2380 \

-p 2379:2379 \

--name etcd \

quay.io/coreos/etcd:3.2.17 \

etcd --name=master2 \

--advertise-client-urls=http://192.168.100.2:2379 \

--listen-client-urls=http://0.0.0.0:2379 \

--initial-advertise-peer-urls=http://192.168.100.2:2380 \

--listen-peer-urls=http://0.0.0.0:2380 \

--initial-cluster-token=etcd-cluster-0 \

--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \

--initial-cluster-state=new \

--auto-tls \

--peer-auto-tls \

--data-dir=/var/lib/etcd

master3

docker run -d \

--restart always \

-v /etc/etcd/ssl/certs:/etc/ssl/certs \

-v /u03/etcd_docker:/var/lib/etcd \

-p 2380:2380 \

-p 2379:2379 \

--name etcd \

quay.io/coreos/etcd:3.2.17 \

etcd --name=master3 \

--advertise-client-urls=http://192.168.100.3:2379 \

--listen-client-urls=http://0.0.0.0:2379 \

--initial-advertise-peer-urls=http://192.168.100.3:2380 \

--listen-peer-urls=http://0.0.0.0:2380 \

--initial-cluster-token=etcd-cluster-0 \

--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \

--initial-cluster-state=new \

--auto-tls \

--peer-auto-tls \

--data-dir=/var/lib/etcd


这样在三台节点上完成ETCD集群的部署,在这里没有使用https,是因为想简化部署过程,也不需要涉及到外部网络,如果有安全认证方面的需求可以按照我上一篇高阶k8s HA 集群搭建(一)里搭建etcd集群的方式,照葫芦画瓢。

如果在部署过程中出现问题,etcd容器没有启动或者一直再重启则通过docker ps -a查看容器id,通过docker logs CONTAINER ID来排查问题。

验证方式:

1.如果你安装了etcdctl则

etcdctl --endpoints=http://192.168.100.1:2379,http://192.168.100.2:2379,http://192.168.100.3:2379 \

cluster-health

etcdctl --endpoints=http://192.168.100.1:2379,http://192.168.100.2:2379,http://192.168.100.3:2379 \

member list

2.直接到etcd容器里验证

docker exec -ti etcd ash

etcdctl member list

etcdctl cluster-health

exit

keepalived

在每个master节点上执行

拉取keepalived镜像

docker pull osixia/keepalived:1.4.4

载入内核相关模块

lsmod | grep ip_vs

modprobe ip_vs

部署keepalived

docker run --net=host --cap-add=NET_ADMIN \

-e KEEPALIVED_INTERFACE=eno16780032 \

-e KEEPALIVED_VIRTUAL_IPS="#PYTHON2BASH:['192.168.100.4']" \

-e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['192.168.100.1','192.168.100.2','192.168.100.3']" \

-e KEEPALIVED_PASSWORD=admin \

--name k8s-keepalived \

--restart always \

-d osixia/keepalived:1.4.4

其中KEEPALIVED_INTERFACE填的是192.168.100.0/24网段所在的网卡,可以通过ip a命令来查看。KEEPALIVED_VIRTUAL_IPS设置的是需要用到的vip。

三台master节点部署完成后通过ping 192.168.100.4的方式验证是否通,或者直接ip a查看第一台部署的master,网卡上是不是多了一个ip。

如果出现问题,也可以通过docker logs k8s-keepalived来调试。

如果失败后清理,重新部署

docker rm -f k8s-keepalived

haproxy

在每个master上执行

拉取haproxy镜像

docker pull haproxy:1.7.8-alpine

创建haproxy配置文件夹

mkdir /etc/haproxy

创建haproxy配置

cat >/etc/haproxy/haproxy.cfg<<EOF

global

  log 127.0.0.1 local0 err

  maxconn 50000

  uid 99

  gid 99

  #daemon

  nbproc 1

  pidfile haproxy.pid

defaults

  mode http

  log 127.0.0.1 local0 err

  maxconn 50000

  retries 3

  timeout connect 5s

  timeout client 30s

  timeout server 30s

  timeout check 2s

listen admin_stats

  mode http

  bind 0.0.0.0:1080

  log 127.0.0.1 local0 err

  stats refresh 30s

  stats uri    /haproxy-status

  stats realm  Haproxy\ Statistics

  stats auth    admin:admin

  stats hide-version

  stats admin if TRUE

frontend k8s-https

  bind 0.0.0.0:8443

  mode tcp

  #maxconn 50000

  default_backend k8s-https

backend k8s-https

  mode tcp

  balance roundrobin

  server master1 192.168.100.1:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3

  server master1 192.168.100.2:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3

  server master1 192.168.100.3:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3

EOF

启动haproxy

docker run -d --name my-haproxy \

-v /etc/haproxy:/usr/local/etc/haproxy:ro \

-p 8443:8443 \

-p 1080:1080 \

--restart always \

haproxy:1.7.8-alpine

验证

浏览器查看状态

http://192.168.100.1:1080/haproxy-status

http://192.168.100.2:1080/haproxy-status

http://192.168.100.3:1080/haproxy-status

master节点初始化

ps:首先需要将相关软件安装一下,k8s相关的组件和镜像

在第一台master上创建新的token并记住(一会儿都要用到)

kubeadm token generate

制作配置文件

vim config.yaml

apiVersion: kubeadm.k8s.io/v1alpha1

kind: MasterConfiguration

kubeProxy:

  config:

    featureGates:

      SupportIPVSProxyMode: true

    mode: ipvs

etcd:

  endpoints:

  - http://192.168.100.1:2379

  - http://192.168.100.2:2379

  - http://192.168.100.3:2379

  dataDir: /u03/etcd_docker

networking:

  serviceSubnet: 10.96.0.0/12

  podSubnet: 10.244.0.0/16

kubernetesVersion: 1.10.0

api:

  advertiseAddress: "192.168.100.1" #每个节点的ip

apiServerExtraArgs:

  endpoint-reconciler-type: lease

controllerManagerExtraArgs:

  node-monitor-grace-period: 10s

  pod-eviction-timeout: 10s

apiServerCertSANs:

- master1

- master2

- master3

- 192.168.100.1

- 192.168.100.2

- 192.168.100.3

- 192.168.100.4

token: hpobow.vw1g1ya5dre7sq06 #之前生成的token

tokenTTL: "0" #token失效时间,0表示永不失效

featureGates:

  CoreDNS: true

我们使用CoreDNS作为k8s内部网络域名解析,使用ipvs做proxy内网负载均衡

kubeadm init --config config.yaml 

systemctl enable kubelet

保存初始化完成之后的join命令

如果丢失可以使用命令"kubeadm token list"获取

# kubeadm join 192.168.100.1:6443 --token hpobow.vw1g1ya5dre7sq06 --discovery-token-ca-cert-hash sha256:0e4f738348be836ff810bce754e059054845f44f01619a37b817eba83282d80f

配置kubectl使用

mkdir -p$HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf$HOME/.kube/config

sudo chown $(id -u):$(id -g)$HOME/.kube/config

或者root 用户可以直接

echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile

source ~/.bash_profile

安装网络插件(只用安装一次)

下载配置

部署网络插件我们这里使用canal,既Calico的策略+flannel的网络,因为在Calico目前还没有很好的支持ipvs

https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/flannel

kubectl apply -f \

https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/rbac.yaml

kubectl apply -f \

https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml

由于canal一些组件需要翻墙,先wget https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml 下来,单独下载里面的镜像,再部署

如果Node有多个网卡的话,参考flannel issues 39701,

https://github.com/kubernetes/kubernetes/issues/39701

需要在canal.yaml中使用--iface参数指定集群主机内网网卡的名称,

否则可能会出现dns无法解析。容器无法通信的情况,需要将canal.yaml下载到本地

修改如下,网卡名称通过ip a自行查看

- name: kube-flannel

          image: quay.io/coreos/flannel:v0.9.1

          command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr", "--iface=eno16780032" ]

查看系统组件运行状况

kubectl get pods --namespace kube-system

kubectl get svc --namespace kube-system

kubectl get nodes

在另外两台master节点上初始化

将在master1 的kubeadm生成证书密码文件分发到master2和master3上面去

scp -r /etc/kubernetes/pki master2:/etc/kubernetes/

scp -r /etc/kubernetes/pki master3:/etc/kubernetes/

生成配置文件

使用和之前master1一样的配置文件

token保持一致

制作配置文件

vim config.yaml

apiVersion: kubeadm.k8s.io/v1alpha1

kind: MasterConfiguration

kubeProxy:

  config:

    featureGates:

      SupportIPVSProxyMode: true

    mode: ipvs

etcd:

  endpoints:

  - http://192.168.100.1:2379

  - http://192.168.100.2:2379

  - http://192.168.100.3:2379

  dataDir: /u03/etcd_docker

networking:

  serviceSubnet: 10.96.0.0/12

  podSubnet: 10.244.0.0/16

kubernetesVersion: 1.10.0

api:

  advertiseAddress: "192.168.100.2" #每个节点的ip

apiServerExtraArgs:

  endpoint-reconciler-type: lease

controllerManagerExtraArgs:

  node-monitor-grace-period: 10s

  pod-eviction-timeout: 10s

apiServerCertSANs:

- master1

- master2

- master3

- 192.168.100.1

- 192.168.100.2

- 192.168.100.3

- 192.168.100.4

token: hpobow.vw1g1ya5dre7sq06 #之前生成的token

tokenTTL: "0" #token失效时间,0表示永不失效

featureGates:

  CoreDNS: true

执行初始化

kubeadm init --config config.yaml

systemctl enable kubelet

保存初始化完成之后的join命令(方便工作节点加入)

等另外两台master部署完成之后

验证

查看状态

kubectl get pod --all-namespaces -o wide | grep master1

kubectl get pod --all-namespaces -o wide | grep master2

kubectl get pod --all-namespaces -o wide | grep master3

kubectl get nodes -o wide

修改master节点相关组件配置指向vip(每一台master都要执行

sed -i's@server: https://192.168.100.*:6443@server: https://192.168.100.4:8443@g'/etc/kubernetes/{admin.conf,kubelet.conf,scheduler.conf,controller-manager.conf}

重启kubelet

systemctl daemon-reload

systemctl restart kubelet docker

查看所有节点状态

kubectl get nodes -o wide

修改kube-proxy的配置

修改kube-proxy的配置指定vip

执行命令

kubectl edit -n kube-system configmap/kube-proxy

将server修改为server: https://192.168.100.4:8443并保存

查看设置

kubectl get -n kube-system configmap/kube-proxy -o yaml

删除重建kube-proxy

kubectl get pods --all-namespaces -o wide | grep proxy

all_proxy_pods=$(kubectl get pods --all-namespaces -o wide | grep proxy | awk'{print $2}'| xargs)

echo$all_proxy_pods

kubectl delete pods$all_proxy_pods-n kube-system

kubectl get pods --all-namespaces -o wide | grep proxy

这样三台HA master节点就搭建完成了

*工作节点

工作节点需要用到刚刚的kubeadm join命令添加

kubeadm join 192.168.100.4:8443 --token hpobow.vw1g1ya5dre7sq06 --discovery-token-ca-cert-hash sha256:0e4f738348be836ff810bce754e059054845f44f01619a37b817eba83282d80f

systemctl enable kubelet

需要的软件参考我的第一篇k8s集群搭建

修改工作节点kubelet配置并重启

sed -i's@server: https://192.168.100.*:6443@server: https://192.168.100.4:8443@g'/etc/kubernetes/kubelet.conf

重启kubelet

systemctl daemon-reload

systemctl restart kubelet docker

查看所有节点状态

kubectl get nodes -o wide


这样高可用集群就搭建完成了。这样的master节点相对于第一种高可用的方式多了haproxy负载均衡,通过负载均衡将三台master apiserver调用起来,实现资源高可用。

本文大量照搬了以下的文献并做了一些自己的修改

centos7使用kubeadm配置高可用k8s集群

kubeadm安装Kubernetes V1.10集群详细文档

上一篇 下一篇

猜你喜欢

热点阅读