猿创征文|云原生|kubernetes二进制1.18单master扩展为多master

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 猿创征文|云原生|kubernetes二进制1.18单master扩展为多master

前言

在此前已经部署了单master节点,但,出于集群稳定性的考虑,需要将其扩展为多master。原单master部署链接:kubernetes二进制安装教程单master_zsk_john的博客-

计划是在此基础上扩展,其中的细节还是比较多的,单master和多master的集群规划计划如下:

单master集群规划

单master集群规划表

序号 ip 角色 hostname 安装的组件
1 192.168.217.16 master        master,k8s-master kube-apiserver,kubelet,kube-controller-manager,kube-proxy,etcd,docker环境
2 192.168.217.17 slave1 slave1,k8s-slave1 kubelet,kube-proxy,etcd,docker环境
3 192.168.217.18 slave2 slave2,k8s-slave2 kubelet,kube-proxy,etcd,docker环境

多master集群规划

多master集群规划表

序号 ip 角色 hostname 安装的组件
1 192.168.217.16 master1 master,k8s-master(master节点) kube-apiserver,kube-controller-manager,kube-proxy,kubelet,etcd,docker环境
2 192.168.217.11

master2

master2,k8s-master2(master节点) kube-apiserver,kube-controller-manager,kube-proxy,kubelet,docker环境
3 192.168.217.17 slave1,node1 slave1,k8s-slave1(work节点) kubelet,kube-proxy,etcd,docker环境
4 192.168.217.18 slave2,node2 slave2,k8s-slave2(work节点) kubelet,kube-proxy,etcd,docker环境
5

192.168.217.17

192.168.217.88(vip)

Load Balancer(Master) slave1,k8s-slave1 nginx,keepalived
6 192.168.217.18 Load Balancer(backup) slave2,k8s-slave2 nginx,keepalived

规划思路:

增加一台新的服务器,安装master节点所必须的三个组件:kube-apiserver,kube-controller-manager,kube-proxy,etcd由于已经是三个节点了,符合集群的奇数规定,因此,新服务器上不安装etcd,负载均衡软件使用的是nginx和keepalived,负载均衡不能安装在master节点上,因为会端口占用,因此,在两个work节点安装的。docker环境是不管哪个节点都必须安装的,kubelet是节点管理服务,因此,master和work节点都安装。

在实际的生产中,当然负载均衡应该是单独的部署在新服务器上。因服务器不够多,也是实验性质,因此,负载均衡安装在了两个work节点上。

扩展部署master节点步骤

一,

新服务器11上面安装ntp时间服务器,与其他服务器做免密配置,设定主机名,四台服务器的hosts内容如下;

[root@centos1 nginx-offline]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.217.16 master  k8s-master
192.168.217.17 slave1 k8s-node1
192.168.217.18 slave2 k8s-node2
192.168.217.11 master2 k8s-master2

hosts文件通过scp命令同步到所有节点。

新服务上安装docker 环境,可简单一点,如果前面是使用二进制安装的docker,在master服务器也就是16服务器上面执行命令:

scp /usr/bin/{docker,dockerd,docker-init,docker-proxy,ctr,runc,containerd,containerd-shim} 192.168.217.11:/usr/bin/
scp /etc/docker/daemon.json master2:/etc/docker
scp /usr/lib/systemd/system/docker.service 192.168.217.11:/usr/lib/systemd/system/

在11服务器上执行命令,启动docker服务并查看docker状态是否正常:

systemctl enable docker && systemctl start docker && systemctl status docker

二,

在Master2创建etcd证书目录:

mkdir -p /opt/etcd/ssl

在master节点,16服务器上,直接拷贝原有的master节点的现有文件到新服务器上,并做相关修改即可,命令如下:

scp -r /opt/kubernetes root@192.168.217.11:/opt
scp -r /opt/cni/ root@192.168.217.11:/opt
scp -r /opt/etcd/ssl root@192.168.217.11:/opt/etcd
scp /usr/lib/systemd/system/kube* root@192.168.217.11:/usr/lib/systemd/system
scp /usr/bin/kubectl root@192.168.217.11:/usr/bin

三,

在master2节点,11服务器上,删除kubelet证书和kubeconfig文件:

删除的原因是kubelet服务会在启动的时候新生成这些文件,如果是旧的文件,将不会启动成功。

rm -f /opt/kubernetes/cfg/kubelet.kubeconfig
rm -f /opt/kubernetes/ssl/kubelet*

四,

仍然在master2节点, 11服务器上,修改配置文件(是三个配置文件,不要遗漏了哦):

修改apiserver、kubelet和kube-proxy配置文件为本地IP:
vim /opt/kubernetes/cfg/kube-apiserver.conf
...
--bind-address=192.168.217.11 \
--advertise-address=192.168.217.11 \
...
vim /opt/kubernetes/cfg/kubelet.conf
--hostname-override=k8s-master2
vi /opt/kubernetes/cfg/kube-proxy-config.yml
hostnameOverride: k8s-master2

五,

在11服务器上启动相关服务:

systemctl daemon-reload
systemctl start kube-apiserver
systemctl start kube-controller-manager
systemctl start kube-scheduler
systemctl start kubelet
systemctl start kube-proxy
systemctl enable kube-apiserver
systemctl enable kube-controller-manager
systemctl enable kube-scheduler
systemctl enable kubelet
systemctl enable kube-proxy

六,

检测是否正常:

kubectl get cs
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-1 Healthy {"health":"true"}
etcd-2 Healthy {"health":"true"}
etcd-0 Healthy {"health":"true"}

此时应该可以看到新的node节点了:

[root@centos1 nginx-offline]# k get no
NAME          STATUS   ROLES    AGE    VERSION
k8s-master    Ready    <none>   9d     v1.18.3
k8s-master2   Ready    <none>   172m   v1.18.3
k8s-node1     Ready    <none>   8d     v1.18.3
k8s-node2     Ready    <none>   8d     v1.18.3

七,

在17和18服务器上都执行:

yum install nginx keepalived -y
systemctl enable nginx keepalived && systemctl start nginx keepalived

八,负载均衡相关配置文件

17主master:

nginx配置文件(17和18的配置文件都一样的):

[root@master ~]# cat /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
    worker_connections 1024;
}
stream {
    log_format  main  '  - []  ';
    access_log  /var/log/nginx/k8s-access.log  main;
    upstream k8s-apiserver {
       server 192.168.217.16:6443;
       server 192.168.217.11:6443;
    }
    server {
       listen 6443;
       proxy_pass k8s-apiserver;
    }
}
http {
    log_format  main  ' -  [] "" '
                      '  "" '
                      '"" ""';
    access_log  /var/log/nginx/access.log  main;
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;
    server {
        listen       80 default_server;
        server_name  _;
        location / {
        }
    }
}

keepalived的配置文件:

[root@master ~]# cat /etc/keepalived/keepalived.conf 
global_defs { 
   notification_email { 
     acassen@firewall.loc 
     failover@firewall.loc 
     sysadmin@firewall.loc 
   } 
   notification_email_from Alexandre.Cassen@firewall.loc  
   smtp_server 127.0.0.1 
   smtp_connect_timeout 30 
   router_id NGINX_MASTER
} 
vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
}
vrrp_instance VI_1 { 
    state MASTER 
    interface ens33
    virtual_router_id 51 # VRRP 路由 ID实例,每个实例是唯一的 
    priority 100    # 优先级,备服务器设置 90 
    advert_int 1    # 指定VRRP 心跳包通告间隔时间,默认1秒 
    authentication { 
        auth_type PASS      
        auth_pass 1111 
    }  
    virtual_ipaddress { 
        192.168.217.88/24
    } 
    track_script {
        check_nginx
    } 
}

18服务器上的keepalived配置文件(两个文件,其中一个是检测脚本,脚本两个节点都要有):

[root@slave2 nginx-offline]# cat /etc/keepalived/check_nginx.sh 
#!/bin/bash
count=$(ps -ef |grep nginx |egrep -cv "grep|$$")
if [ "$count" -eq 0 ];then
exit 1
else
exit 0
fi
[root@slave2 nginx-offline]# cat /etc/keepalived/keepalived.conf 
global_defs { 
   notification_email { 
     acassen@firewall.loc 
     failover@firewall.loc 
     sysadmin@firewall.loc 
   } 
   notification_email_from Alexandre.Cassen@firewall.loc  
   smtp_server 127.0.0.1 
   smtp_connect_timeout 30 
   router_id NGINX_MASTER
} 
vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
}
vrrp_instance VI_1 { 
    state BACKUP 
    interface ens33
    virtual_router_id 51 # VRRP 路由 ID实例,每个实例是唯一的 
    priority 80    # 优先级,备服务器设置 90 
    advert_int 1    # 指定VRRP 心跳包通告间隔时间,默认1秒 
    authentication { 
        auth_type PASS      
        auth_pass 1111 
    }  
    virtual_ipaddress { 
        192.168.217.88/24
    } 
    track_script {
        check_nginx
    } 
}

九,

重启负载均衡相关服务

systemctl restart nginx keepalived

十,

kube-apiserver服务所使用的证书文件内没有写vip地址,因此,16服务器上的kube-apiserver服务将会启动失败,需要重新生成证书:

在master节点,16服务器上,该文件内添加"192.168.217.88",

[root@master ~]# cat k8s/server-csr.json 
{
"CN": "kubernetes",
"hosts": [
"10.0.0.1",
"127.0.0.1",
"192.168.217.16",
"192.168.217.17",
"192.168.217.18",
"192.168.217.88",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}

重新生成证书:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes server-csr.json | cfssljson -bare server

拷贝证书文件(拷贝到本地和新master上):

cp server*pem /opt/kubernetes/ssl/
scp /opt/kubernetes/ssl/server*pem master2:/opt/kubernetes/ssl/

重启服务,使得相关证书生效:

systemctl restart kube-apiserver kubelet

十一,

所有配置文件内添加VIP的IP地址192.168.217.88 ,并重启相关服务。

sed -i 's#192.168.217.16:6443#192.168.217.88:6443#' /opt/kubernetes/cfg/*
systemctl restart kubelet kube-proyx

十二,

测试单元

在17服务器上,也就是负载均衡的主节点上,可以看到ens33网卡两个ip:

[root@slave1 ~]#  ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:e9:9e:89 brd ff:ff:ff:ff:ff:ff
    inet 192.168.217.17/24 brd 192.168.217.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet 192.168.217.88/24 scope global secondary ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fee9:9e89/64 scope link 
       valid_lft forever preferred_lft forever

此时,停止17上的nginx,在18服务上  ,ip a 命令应该可以看到ens33网卡两个IP,证明负载均衡漂移成功。

通过VIP 可以看到k8s版本:

[root@centos1 nginx-offline]# curl -k https://192.168.217.88:6443/version
{
  "major": "1",
  "minor": "18",
  "gitVersion": "v1.18.3",
  "gitCommit": "2e7996e3e2712684bc73f0dec0200d64eec7fe40",
  "gitTreeState": "clean",
  "buildDate": "2020-05-20T12:43:34Z",
  "goVersion": "go1.13.9",
  "compiler": "gc",
  "platform": "linux/amd64"
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
3天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
25 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
10天前
|
Kubernetes 应用服务中间件 nginx
二进制安装Kubernetes(k8s)v1.32.0
本指南提供了一个详细的步骤,用于在Linux系统上通过二进制文件安装Kubernetes(k8s)v1.32.0,支持IPv4+IPv6双栈。具体步骤包括环境准备、系统配置、组件安装和配置等。
116 10
|
15天前
|
弹性计算 调度 数据中心
阿里云 ACK One 注册集群云上弹性:扩展业务新利器
随着企业数字化转型深入,传统IDC数据中心因物理容量限制,难以实现动态扩容,缺乏弹性能力。阿里云ACK One注册集群凭借其高度灵活性和丰富资源选择,成为解决此问题的最佳方案。通过与阿里云资源的整合,ACK One不仅实现了计算资源的按需扩展,提高了资源利用率,还通过按需付费模式降低了成本,使企业能够更高效地应对业务增长和高峰需求。
|
29天前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
1月前
|
Kubernetes Cloud Native 开发者
云原生入门:Kubernetes的简易指南
【10月更文挑战第41天】本文将带你进入云原生的世界,特别是Kubernetes——一个强大的容器编排平台。我们将一起探索它的基本概念和操作,让你能够轻松管理和部署应用。无论你是新手还是有经验的开发者,这篇文章都能让你对Kubernetes有更深入的理解。
|
1月前
|
Prometheus Kubernetes 监控
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
|
1月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes和Docker的协同工作
【10月更文挑战第43天】在云计算时代,云原生技术成为推动现代软件部署和运行的关键力量。本篇文章将带你了解云原生的基本概念,重点探讨Kubernetes和Docker如何协同工作以支持容器化应用的生命周期管理。通过实际代码示例,我们将展示如何在Kubernetes集群中部署和管理Docker容器,从而为初学者提供一条清晰的学习路径。
|
1月前
|
Kubernetes Cloud Native 云计算
云原生入门:Kubernetes 和容器化基础
在这篇文章中,我们将一起揭开云原生技术的神秘面纱。通过简单易懂的语言,我们将探索如何利用Kubernetes和容器化技术简化应用的部署和管理。无论你是初学者还是有一定经验的开发者,本文都将为你提供一条清晰的道路,帮助你理解和运用这些强大的工具。让我们从基础开始,逐步深入了解,最终能够自信地使用这些技术来优化我们的工作流程。
|
3天前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
18 2
|
15天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。