kubernetes 跨机房部署方案

由于业务需要分散在多个机房,如果使用一个deployment部署,则实现流量拆分、切换等,会十分不方便。故考虑将服务按照区域进行拆分

1、通过node label 定义服务器的区域,例如:
kubectl label nodes vm101 region=bj
kubectl label nodes vm102 region=sh
kubectl label nodes vm103 region=mirror

每个区域,一个deployment 和svc,deployment通过node的label 部署在指定节点上。

├── all.service.yaml --------all节点可以获取到gz/sh/mirror的endpoint 列表
├── gz
│ ├── deployment.yaml
│ └── service.yaml
├── ingress.yaml
├── mirror
│ ├── deployment.yaml
│ └── service.yaml
├── nginx.conf
├── php_conf.cm.yaml
└── sh
├── deployment.yaml
└── service.yaml

原文地址:http://blog.51cto.com/devops9527/2324826

时间: 2024-11-09 02:59:31

kubernetes 跨机房部署方案的相关文章

etcd跨机房部署方案

使用ETCD做为元数据方便快捷,但是谈到跨机房灾备可能就迷糊了,我们在做节日灾备的时候同样遇到了问题, 通过查阅官方文档找到了解决方案,官方提供make-mirror方法,提供数据镜像服务 注意: make-mirror 的使用需要依赖于API版本3, 使用API2的无法通过该工具做数据同步 有关ETCD的编译安装这里就不在说明了, 不明白的可以参考官方说明:https://github.com/coreos/etcd 1. 启动集群1 #!/bin/bash nohup etcd --name

[转]跨机房问题

跨机房问题一直都是一个老大难的问题,先看传统数据库的跨机房方案. Master/Slave方案 这是最常用的方案,适用于大多数需求.Master将操作日志实时地发送到Slave,Slave当成Master的一个Hot Backup.Master宕机时,服务切换到Slave,需要修改客户端逻辑使得Master失效时自动寻找新的Master. 这个方案有一个问题就是数据库的Master和Slave一般不是强同步的,所以,切换到Slave后可能丢失宕机前的少量更新.如果将Master和Slave做成强

Step4:SQL Server 跨网段(跨机房)复制

一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 解决方案(Solution) 搭建过程(Process) 注意事项(Attention) 参考文献(References) 二.背景(Contexts) 搭建SQL Server复制的时候,如果网络环境是局域网内,通过主机名就可以实现了,但是如果是跨网段.跨机房异地搭建复制的时候就需要注意了,因为SQL Server复制不支持通过IP连接分发服务器,那有什么办法解决跨网段.跨机房的问题呢?

vitess元数据跨机房灾备解决方案

测试使用vitess的时候发现vitess元数据的实现有多种方案,etcd, etcd2, zk,zk2, 由于刚开始测试的时候使用的是基于k8s集群+etcd的,以下就分步说明灾备实现方案: 1. 前置条件 元数据实现方式必须选择etcd2, 即在启动的时候需要增加参数 -topo_implementation etcd2 #元数据实现方案, 此处一定需要选择etcd2, 如果选择etcd的话无法使用etcd API3提供的 etcdctl make-mirror进行数据同步 -topo_gl

SQL Server 跨网段(跨机房)FTP复制

SQL Server 跨网段(跨机房)FTP复制 2013-09-24 17:53 by 听风吹雨, 1497 阅读, 4 评论, 收藏, 编辑 一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 搭建过程(Process) 注意事项(Attention) 参考文献(References) 二.背景(Contexts) 搭建SQL Server复制的时候,如果网络环境是局域网内,通过主机名就可以实现了,但是如果是跨网段.跨机房异地搭建复制的时

应用多机房部署

通常一个产品,内部是需要很多子系统一起协助的,像有些电商系统,可能需要几百个系统一起协助.假设下面这样一种场景,假设应用a部署在机房room1, 在room1的其他应用可以调用应用a的接口,然后还有很多的子系统是部署在room2这个机房的,room2中的应用也需要调用到应用a,那么这样 room2中的应用调用room1中的a应用时,就有因为跨机房导致的时延问题.如果系统的qps要求很高,那么应用a最好也部署在room2,实行多机房部署. 具体内容请参看我的csdn博客文章: 应用多机房部署

eql高可用部署方案

运行环境 服务器两台(后面的所有配置案例都是以10.96.0.64和10.96.0.66为例) 操作系统CentOS release 6.2 必须要有共同的局域网网段 两台服务器都要安装keepalived(双机热备)和eql服务 软件部署 keepalived 部分 keepalived是一个用于做双机热备(HA)的软件,常和haproxy联合起来做热备+负载均衡,达到高可用. keepalived通过选举(看服务器设置的权重)挑选出一台热备服务器做MASTER机器,MASTER机器会被分配到

利用otter实现跨机房数据同步

Otter: otter是阿里开源的一个分布式数据库同步系统,尤其是在跨机房数据库同步方面,有很强大的功能.它是基于数据库增量日志解析,实时将数据同步到本机房或跨机房的mysql/oracle数据库. 环境:(由于环境隐私原因,环境中使用的外部IP隐藏) 网络图: 实验环境: A机房(公司内网)<===>B机房(云服务环境内网) 数据源(mysql需开启binlog,binlog_format=ROW): Mysql_A:192.168.1.20:3306(外部IP:xx.xx.xx.xx:3

mysql跨机房异地区的主从数据库同步备份业务实现解决方案

mysql跨机房异地区的主从数据库同步备份业务实现解决方案 背景 早期,阿里巴巴B2B公司因为存在杭州和美国双机房部署,存在跨机房同步的业务需求.不过早期的数据库同步业务,主要是基于trigger的方式获取增量变更,不过从2010年开始,阿里系公司开始逐步的尝试基于数据库的日志解析,获取增量变更进行同步,由此衍生出了增量订阅&消费的业务,从此开启了一段新纪元. ps. 目前内部版本已经支持mysql和oracle部分版本的日志解析,当前的canal开源版本支持5.7及以下的版本(阿里内部mysq