在公司,使用dns切换,可能会比keepalived+haproxy,更精简的易维护. 毕竟,高可用只是偶尔切换,不是时时切换. 且dns解析在自己可控时,更不会影响k8s线上使用了. (部分代码,由于担心太冗长,已使用xxx代替,这些xxx完全可以自己生成的) 使用步骤如下: 先在每个master上安装etcd,运行如下命令: sh k8s.sh k8s.xxx.com.cn etcd 等每个master上的etcd安装好之后,运行如下命令: sh k8s.sh k8s.xxx.com.cn

# 安装 nginx yum install nginx -y # 配置nginx4层代理 /etc/nginx/nginx.conf stream { upstream kube-apiserver { server 10.4.7.21:6443 max_fails=3 fail_timeout=30s; server 10.4.7.22:6443 max_fails=3 fail_timeout=30s; } server { listen 7443; proxy_connect_timeo

一.项目介绍 项目致力于让有意向使用原生kubernetes集群的企业或个人,可以方便的.系统的使用二进制的方式手工搭建kubernetes高可用集群.并且让相关的人员可以更好的理解kubernetes集群的运作机制. 软件版本 os centos7.7(ubuntu也适用,需要替换部分命令) kubernetes 1.16.2 etcd 3.4.3 docker 18.06 calico 3.10.1-2 coredns 配置策略 kube-apiserver: 使用节点本地 nginx 4

00.组件版本和配置策略 组件版本 Kubernetes 1.14.2 Docker 18.09.6-ce Etcd 3.3.13 Flanneld 0.11.0 插件: Coredns Dashboard Metrics-server EFK (elasticsearch.fluentd.kibana) 镜像仓库: docker registry harbor 主要配置策略 kube-apiserver: 使用节点本地 nginx 4 层透明代理实现高可用: 关闭非安全端口 8080 和匿名访

文章转载自:https://i4t.com/5451.html 背景 Kubernetes 1.24新特性 从kubelet中移除dockershim,自1.20版本被弃用之后,dockershim组件终于在1.24的kubelet中被删除.从1.24开始,大家需要使用其他受到支持的运行时选项(例如containerd或CRI-O):如果您选择Docker Engine作为运行时,则需要使用cri-dockerd. 对于kubelet和containerd重要提示 在升级至1.24之前,请确认c

一.高可用原理   配置一台新的master节点,然后在每台node节点上安装nginx,nginx通过内部的负载均衡将node节点上需要通过访问master,kube-apiserver组件的请求,反代到两台k8s-master节点上,这样就可以实现master节点的高可用,当任意一台master节点宕机后,也可以通过nginx负载均衡放文档另一个master节点上.kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leade

1. 部署keepalived - apiserver高可用(任选两个master节点) 1.1 安装keepalived # 在两个主节点上安装keepalived(一主一备) $ yum install -y keepalived 1.2 创建keepalived配置文件 # 创建目录 $ ssh <user>@<master-ip> "mkdir -p /etc/keepalived" $ ssh <user>@<backup-ip>

  http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=209805123&idx=1&sn=ced8d67c3e2cc3ca38ef722949fa21f8&3rd=MzA3MDU4NTYzMw==&scene=6#rd 主题 开源 本文根据冯磊和赵星宇在“高可用架构”微信群所做的HttpDNS智能缓存库原理整理而成,转发请注明来自微信公众号ArchNotes. 冯磊,目前主要从事手机应用平台的构建,任职新浪网

之前说到了NamedManager单机版的配置,下面说下DNS+NamedManager双机高可用的配置方案: 1)机器环境 主机名 ip地址 dns01.kevin.cn 192.168.10.202 dns02.kevin.cn 192.168.10.203 VIP地址:192.168.10.190 两台机器做好主机名及hosts绑定 [root@dns01 ~]# vim /etc/hosts ...... 192.168.10.202 dns01.kevin.cn 192.168.10.

转:https://www.cnblogs.com/mikeluwen/p/7068356.html 整体架构: 1.IP地址规划: Dns1:172.28.0.54 Dns2:172.28.0.55 Dr服务器主:172.28.0.57 Dr服务器从:172.28.0.67 Vip:172.28.0.99 原理过程: Lvs+keepalived实现高性能高可靠性负载均衡,这里使用dr模式,客户机访问负载均衡服务器,会调度到后面的真实服务器上,真实服务器直接将结果返回,如果主调度服务器除了问题

因为篇幅原因,AlwaysOn可用性组被拆成了两部分:理论部分和实战部分.而实战部分又被拆成了准备工作和AlwaysOn可用性组搭建. 三篇文章各自的链接: SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(理论篇) SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域.DNS服务器和Windows故障转移群集(准备工作) SQL Server ->> 高可用与灾难恢复(H

整体架构: 1.IP地址规划: Dns1:172.28.0.54 Dns2:172.28.0.55 Dr服务器主:172.28.0.57 Dr服务器从:172.28.0.67 Vip:172.28.0.99 原理过程: Lvs+keepalived实现高性能高可靠性负载均衡,这里使用dr模式,客户机访问负载均衡服务器,会调度到后面的真实服务器上,真实服务器直接将结果返回,如果主调度服务器除了问题,vip会漂到从服务器继续提供负载均衡,主恢复后vip重新漂到主服务器,后面的真实服务器如果出现问题,

1.  背景 例如,存在一套redis主从(主从节点在不同的主机上),应用程序通过主库的ip进行读写操作. 但是,主库一旦出现故障,虽然有从库,且从库提升为主库,但是应用程序如果想使用从库则必须修改配置,重启应用方可生效.如用此情况,则涉及的人员比较多,且应用程序恢复使用的时间比较长.对于此情况,可以采取以下2种解决方式解决: a)  配置VIP 在Redis主库服务器上配置vip,当主库出现问题时,配置脚本将vip自动切换至从节点,并将从节点提升为读写状态.应用程序中配置的是vip,主库异常时

Centos7.2 下DNS+NamedManager高可用部署方案完整记录 之前说到了NamedManager单机版的配置,下面说下DNS+NamedManager双机高可用的配置方案: 1)机器环境 主机名            ip地址 dns01.kevin.cn   172.22.51.65 dns02.kevin.cn   172.22.51.74 VIP地址:172.22.51.75 两台机器做好主机名及hosts绑定 [root@dns01 ~]# vim /etc/hosts

之前我们搭建的 k8s 集群只用了1台 master ,可用性不高,这两天开始搭建高可用集群,但由于之前用 kubeadm 命令创建集群时没有使用 --control-plane-endpoint 参数,无法直接升级现有集群,只能重新创建高可用(High-Availability)集群. 高可用集群的原理很简单,多台 master ,每台都保存集群数据(etcd),所有 nodes 通过专门搭建的负载均衡访问 api server ,这样当部分 master 宕机时,对集群正常运行无影响. 我们

写在前面:  1. 该文章部署方式为二进制部署. 2. 版本信息 k8s 1.7.6,etcd 3.2.9 3. 高可用部分 etcd做高可用集群.kube-apiserver 为无状态服务使用haproxy做负载均衡,kube-controller-manager和kube-scheduler使用自身的选举功能,无需考虑高可用问题. 环境说明: 本环境中网络说明,宿主机及node网段为192.168.1.x/24,service cluster网段为172.16.x.x/16 ,pod网段为1

说明:部署的过程中请保证每个命令都有在相应的节点执行,并且执行成功,此文档已经帮助几十人(仅包含和我取得联系的)快速部署k8s高可用集群,文档不足之处也已更改,在部署过程中遇到问题请先检查是否遗忘某个步骤,文档中每个步骤都是必须的. 经测验此文档也适合高可用部署k8s v.12,只需修改对应版本号就可. 1.部署架构 详细架构: 2.基本配置 主机名 IP地址 说明 组件 k8s-master01 ~ 03 192.168.20.20 ~ 22 master节点 * 3 keepalived.n

0x00 概述 本次采用二进制文件方式部署,本文过程写成了更详细更多可选方案的ansible部署方案 https://github.com/zhangguanzhang/Kubernetes-ansible和之前的步骤差不多都是和kubeadm步骤一样,不过这次所有kubelet全部走bootstrap不会像之前master上的kubelet生成证书,另外证书换成openssl生成 不建议使用secureCRT这个ssh软件复制本篇博客内容的命令,因为它的部分版本对包含多条命令的处理结果并不完美

原理和架构图参考上一篇,这里只记录操作步骤.由于东西较多,篇幅也会较长. etcd version: 3.2.11 kube version: 1.8.4 contiv version: 1.1.7 docker version: 17.03.2-ce OS version: debian stretch 三个ETCD节点(contiv插件也要使用etcd,这里每个节点复用跑2个etcd实例) 192.168.5.84 etcd0,contiv0 192.168.5.85 etcd1,conti

Kubernetes作为容器应用的管理平台,通过对pod的运行状态进行监控,并且根据主机或容器失效的状态将新的pod调度到其他node上,实现了应用层的高可用. 针对kubernetes集群,高可用性还包含以下两个层面的考虑: etcd存储的高可用 master节点的高可用 在开始之前,先贴一下架构图: etcd作为kubernetes的中心数据库,必须保证其不是单点.不过etcd集群的部署很简单,这里就不细说了,之前写过一键部署脚本,有兴趣的同学可以往前翻. 在k8s全面容器化加上各种验证机制