K8s-1.15.1集权高可用搭建

K8s-1.15.1集群高可用搭建

引入：K8s组件框架回顾

组件高可用

ETCD高可用
- Kubernetes的存储层使用的是Etcd。Etcd是CoreOS开源的一个高可用强一致性的分布式存储服务，Kubernetes使用Etcd作为数据存储后端，把需要记录的pod、rc、service等资源信息存储在Etcd中
- Etcd使用raft算法将一组主机组成集群，raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。leader 和 follower 之间保持心跳。如果 follower在一段时间内没有收到来自leader的心跳，就会转为 candidate，发出新的选主请求
- 在处于正常的状态时，集群中只会存在一个 Leader，其余的服务器都是 Follower
  - Follower：群众，被动接收Leader发送的请求，所有的节点刚开始的时候是处于Follower状态
  - Candidate：候选人，由Follower向Leader转换的中间状态
  - Leader：领导，负责和客户端交互以及日志复制(日志复制是单向的，即Leader发送给Follower)，同一时刻最多只有一个Leder存在

kube-scheduler和kube-controller-manager高可用
- Kubernetes的管理层服务包括kube-scheduler和kubecontroller-manager。kube-scheduler和kube-controllermanager使用一主多从的高可用方案，在同一时刻只允许一个服务处于具体的任务。Kubernetes中实现了一套简单的选主逻辑，依赖Etcd实现scheduler和controller-manager的选主功能
- 如果scheduler和controller-manager在启动的时候设置了 leader-elect参数，它们在启动后会先尝试获取leader节点身份，只有在获取leader节点身份后才可以执行具体的业务逻辑。它们分别会在Etcd中创建kube-scheduler和kube-controllermanager的endpoint，endpoint的信息中记录了当前的leader 节点信息，以及记录的上次更新时间。leader节点会定期更新 endpoint的信息，维护自己的leader身份。每个从节点的服务都会定期检查endpoint的信息，如果endpoint的信息在时间范围内没有更新，它们会尝试更新自己为leader节点。scheduler服务以及controller-manager服务之间不会进行通信，利用Etcd的强一致性，能够保证在分布式高并发情况下leader节点的全局唯一性

Apiserver高可用--web服务器
- Kubernetes 的接入层服务主要是 kube-apiserver。Apiserver 本身是无状态的服务，它的主要任务职责是把资源数据存储到 Etcd 中，后续具体的业务逻辑是由 scheduler 和 controllermanager 执行的

kubernetes优点之处：选举机制，注册端点机制结合所有高可用方案成以下最终高可用方案

高可用集群搭建方案
- 基于kubernetes本身负载调度器机制搭建
  - Sealos：https://github.com/fanux/sealos #最优方案
- 基于nginx或者haproxy代理方式：以下几种比较出名
  - https://kubeoperator.io/ --跳板机隶属于旗下
  - https://www/rancher.cn/ --编排工具
  - https://github.com/wise2c-devops/breeze/blob/master/BreezeManual-CN.md
    
    此公司出名在于是国内第一家向kuberbetes提供了一致性认证的公司
Sealos架构图--思想的改变--完美

注释：

kubectl连接apiserver：本节点apiserver地址即可，没有并发量，不负载均衡

controller-manger和scheduler连接apiserver：通过回环接口

node节点：kubelet和kubeproxy，添加ipvs集群ip，进行负载 kubelet可监听master状态，死了会踢出

node节点里会添加hosts域名解析 apiserver.cluster.local

master节点也可添加会出现在ipvs规则中，即通过规则来进行集群间的通讯

matster端中kubelet和kube proxy(以pod方式运行)：怎样访问到apiserver？

kubelet：以进程方式运行，找hosts文件的域名解析进行集群的访问

kube proxy：以pod方式运行，基于集群的svc网络通信(具有负载能力)

Sealos特性--优点
- 99年证书--kubeadm默认签发是一年，可以修改源码实现99年
- 不依赖ansible haproxy keepalived, 一个二进制工具，0依赖
- 离线安装，不同kubernetes版本下载对应不同版本的资源包即可,离线包包含所有二进制文件配置文件和镜像
- 高可用通过ipvs实现的localLB，占用资源少，稳定可靠，类似 kube-proxy的实现
- 几乎可兼容所有支持systemd的x86_64架构的环境
- ........

系统初始化

设置系统主机名以及Host文件的相互解析
- hostnamectl set-hostname k8s-master01
- 向每个节点发送下hosts文件
安装依赖包--每个节点都执行

yum install -y conntrack ntpdate ntp ipvsadm ipset iptables curl sysstat libseccomp wget vim net-tools git

设置防火墙并设置空规则

关闭Selinux

swapoff -a && sed -i '/ swap / s/^(.*)$/#\1/g' /etc/fstab

setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

调整内核参数

$ cat > kubernetes.conf <<EOF
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1
net.ipv4.tcp_tw_recycle=0
vm.swappiness=0 # 禁止使用 swap 空间，只有当系统 OOM
时才允许使用它
vm.overcommit_memory=1 # 不检查物理内存是否够用
vm.panic_on_oom=0 # 开启 OOM
fs.inotify.max_user_instances=8192
fs.inotify.max_user_watches=1048576
fs.file-max=52706963
fs.nr_open=52706963
net.ipv6.conf.all.disable_ipv6=1
net.netfilter.nf_conntrack_max=2310720
EOF
$ cp kubernetes.conf /etc/sysctl.d/kubernetes.conf
$ sysctl -p /etc/sysctl.d/kubernetes.conf

调整系统时区--基于chrony服务

权重需注意，三个主节点不能一致，10、11、12即可，重启服务，设置开机自启

systemctl restart chronyd && systemctl enable chronyd

每个节点关闭不需要的服务

systemctl stop postfix && systemctl disable postfix

设置rsyslogd和systemd journald服务

mkdir /var/log/journal # 持久化保存日志的目录
mkdir /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/99-prophet.conf <<EOF
[Journal]
# 持久化保存到磁盘
Storage=persistent

# 压缩历史日志
Compress=yes

SyncIntervalSec=5m
RateLimitInterval=30s
RateLimitBurst=1000

# 最大占用空间 10G
SystemMaxUse=10G

# 单日志文件最大 200M
SystemMaxFileSize=200M

# 日志保存时间 2 周
MaxRetentionSec=2week

# 不将日志转发到 syslog
ForwardToSyslog=no
EOF
$ systemctl restart systemd-journald