etcd

docker flannel网络部署和路由走向分析

风流意气都作罢 提交于 2020-10-29 07:17:35
1.flannel介绍 flannel是coreos开发的容器网络解决方案。flannel为每个host分配一个subnet,容器从此subnet中分配ip。这些ip可以在host间路由,容器间无需nat和port mapping就可以跨主机通讯。 每个subnet都是从一个更大的ip池中划分的,flannel会在每个主机上运行一个叫flanneld得agent,其职责是从ip池中分配subnet。为了在各个主机间共享信息,flannel用etcd存放网络配置,已分配的subnet,host的ip等信息。 数据包通过backend在主机间转发。 flannel提供了多种backend,最常用的有vxlan和host-gw。 2.部署实验环境 三个虚机 docker1 docker2 docker3? etcd安装在docker1 docker1 docker2 docker3上运行flanneld 注:为了更方便的验证flannel和etcd所以docker1也安装了flannel, 其实可以不用在docker1安装 centos7自带了软件包,直接yum安装即可 2.1? 安装配置etcd yum -y install etcd [root @docker1 ~] # systemctl start etcd? && systemctl enable etcd [root

Docker网络解决方案

試著忘記壹切 提交于 2020-10-29 05:25:33
原文链接: https://www.cnblogs.com/kevingrace/p/6859114.html Docker跨主机容器间网络通信实现的工具有Pipework、Flannel、Weave、Open vSwitch(虚拟交换机)、Calico, 其中Pipework、Weave、Flannel,三者的区别是: Weave的思路 在每个宿主机上布置一个特殊的route的容器,不同宿主机的route容器连接起来。 route拦截所有普通容器的ip请求,并通过udp包发送到其他宿主机上的普通容器。这样在跨机的多个容器端看到的就是同一个扁平网络。 weave解决了网络问题,不过部署依然是单机的。 Flannel的思路 Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。但在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到,也就是相互ping通。Flannel设计目的就是为集群中所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得"同属一个内网"且"不重复的"IP地址

kubernetes实战(二十五):kubeadm 安装 高可用 k8s v1.13.x

谁说我不能喝 提交于 2020-10-28 15:01:24
1、系统环境   使用kubeadm安装高可用k8s v.13.x较为简单,相比以往的版本省去了很多步骤。   kubeadm安装高可用k8s v.11 和 v1.12 点我   主机信息 主机名 IP地址 说明 组件 k8s-master01 ~ 03 192.168.20.20 ~ 22 master节点 * 3 keepalived、nginx、etcd、kubelet、kube-apiserver k8s-master-lb 192.168.20.10 keepalived虚拟IP 无 k8s-node01 ~ 08 192.168.20.30 ~ 37 worker节点 * 8 kubelet   主机配置 [root@k8s -master01 ~]# hostname k8s - master01 [root@k8s -master01 ~]# free - g total used free shared buff/ cache available Mem: 3 1 0 0 2 2 Swap: 0 0 0 [root@k8s -master01 ~]# cat /proc/cpuinfo | grep process processor : 0 processor : 1 processor : 2 processor : 3 [root@k8s -master01

2020 深圳 Gopher Meetup 上线啦!

只愿长相守 提交于 2020-10-28 07:02:55
10.17 Gopher Meetup 深圳站 Go 中国社区联合华为云,即将为深圳的 Gopher 们带来一场技术盛宴。本次 Meetup 邀请了来自华为云微服务、华为云边缘计算、腾讯IEG和腾讯云的技术专家们,交流分享使用 Go 语言的开发和应用经验。干货内容,现场交流,不容错过。 时间:2020.10.17 13:30-17:30 地点:广东深圳市南山区科园路1001号深圳市软件产业基地4A栋一层 Tips:性急的 Gopher 可以直接点击文末“阅读原文”进行报名~ No.1 华为云的go语言云原生实践 田晓亮|华为云工程师 负责华为云微服务相关产品的架构设计和落地,开发了国内首个go语言微服务框架和服务网格方案。国内早期云服务从业者,在PaaS,微服务,混合云,Devops,APM方向均有深入的实践经验。 内容简介 华为进军云计算后,就引入了kubernetes,promethues等云原生项目,自然也开始大范围使用go语言自研云服务,几年前go的生态也不完善,所以这时候自然就是要自己从头到尾编写工具库,另外也要落地微服务架构模式,自然有大量基础能力需要编写,go chassis就是在这样的背景下诞生的,我将介绍如何利用编写并在华为云治理大规模go云原生应用。 No.2 服务网格在边缘计算领域的实践与探索 李呈隆|华为云边缘云创新Lab工程师 华为云边缘云创新Lab工程师

Go 语言编程 — 代码规范

[亡魂溺海] 提交于 2020-10-26 08:26:54
目录 文章目录 目录 一个项目使用单个 GOPATH import 规范 代码风格 一个项目使用单个 GOPATH GOPATH 指定了 Golang 项目的 Workspace,Golang 是支持多 GOPATH 的,也就是说:在同一个 Golang 项目中可以同时拥有多个运行环境。多 GOPATH 支持带来了一定的灵活度,但也会导致某些副作用,例如:软件版本的一致性。 诸如 Etcd 或 Camlistore 这样的大项目通常会使用 godep 类似的依赖包管理工具,将所有依赖都保存到某个目录中。也就是说,这些项目都会要求使用一个单一的 GOPATH,它们只能在这个目录内找到对应的版本。 简而言之,如果你认为项目需要一个独立的 GOPATH,那么就创建它,但不要尝试在一个项目中使用多个 GOPATH。 import 规范 使用 goimports 工具进行管理:能够在保存 *.go 文件时自动格式化文件并检查 import 规范。如果使用的包没有导入,则自动导入;如果导入的包没有被使用,则自动删除。 $ go get golang.org/x/tools/cmd/goimports 坚持使用分行导入,即便只导入一个包: import ( "fmt" ) 导入多个包时注意按照类别顺序并使用空行区分:标准库包,第三方包,程序内部包: import ( "encoding/json

附007.Docker全系列大总结

匆匆过客 提交于 2020-10-26 04:26:48
Docker全系列总结如下,后期不定期更新。 欢迎基于学习、交流目的的转载和分享,禁止任何商业盗用,同时希望能带上原文出处,尊重ITer的成果,也是尊重知识。 若发现任何错误或纰漏,留言反馈或右侧添加本人反馈。 正篇 001.Docker简介概述 002.Docker安装部署 003.Docker容器管理 004.Docker镜像管理 005.Docker存储管理 006.Docker网络管理 007.基于Docker的Etcd分布式部署 008.Docker Flannel+Etcd分布式网络部署 009.Docker Compose部署及基础使用 010.Docker Compose构建WordPress实战 011.Docker Compose部署Zabbix实战 012.Docker仓库管理 013.Docker私有仓库多Harbor同步部署 014.Docker Harbor+Keepalived+LVS+共享存储高可用架构 附加篇 附001.Docker阿里云Registry加速器配置 附002.Docker常见命令 附003.Docker Compose命令详解 附004.Docker Compose环境变量说明 附005.Docker Compose文件详解 附006.harbor.cfg配置文件详解 来源: oschina 链接: https://my

k8s创建pod和service的过程

≯℡__Kan透↙ 提交于 2020-10-26 03:56:51
k8s创建pod过程 通过图片进行解释 etcd键值库只对API server开放,API server就是k8s集群中的控制中心,一般对API server所在的Master做集群,避免因单点故障影响k8s集群中业务的访问。 通过kubectl命令输入create pod命令 创建命令到达API server后,API server把创建pod的信息写入到etcd键值库中 API server把创建新pod的需求传给scheduler,scheduler通过算法计算分配到合适的Node节点,分配绑定到后端Node上的信息传回至API server,API server在把此信息写入到etcd键值库中 API server传递新建pod信息至Scheduler指定node节点的kubelet程序,kubelet接管后,创建出本地指定的container后,完成信息返回至API server API server把新建好的pod信息写入到etcd键值库中 至此,一个简单的kubectl create POD_NAME ***就新建完成 创建pod节点的service 通过kubectl提交一个pod的service创建请求 Controller Manager会通过对应的Label标签查询到相关的pod实例,生成Serveice的Endpoints信息,并通过API

Kubernetes系列之介绍篇(转)

强颜欢笑 提交于 2020-10-26 00:05:23
add by zhj: k8s是容器的分布式管理工具,Google的技术水平太牛了。在大数据时代,提出了三驾马车,MapReduce, GFS, BigTable,后来人们根据这三篇论文开发出Hadoop,HDFS,Hbase,用于管理大规模集群实现大数据的离线计算与存储,那时,调度的还是虚拟机或物理机。后来容器化技术出现,Google又抓住了,虽然Docker不是Google开发的,但其调度管理系统k8s是其开发的,k8s是docker的上层,用于管理大规模的docker集群。计算机时代,对大规模集群的管理极其重要,可以用其实现非常强大的功能,这也是云计算的最重要的技术之一。 原文: https://www.cnblogs.com/xhyan/p/6656062.html 作者: 純黑色 Kubernetes介绍 1.背景介绍   云计算飞速发展     - IaaS     - PaaS     - SaaS   Docker技术突飞猛进     - 一次构建,到处运行     - 容器的快速轻量     - 完整的生态环境 2.什么是kubernetes   首先,他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度

架构师都该懂的 CAP 定理

£可爱£侵袭症+ 提交于 2020-10-25 13:44:13
面对可能出现的网络延迟,不可预估的请求流量等情况,设计一个分布式系统,我们通常围绕系统高可用,数据一致性的目标去规划和实现,想要完全实现这个目标,却并非易事。由此,分布式系统领域诞生了一个基本定理,即 CAP 定理,用于指导分布式系统的设计,从系统高可用,数据一致性,网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来,让系统设计者只需根据业务场景特点,进行权衡设计适合业务场景的分区容错一致性模型即可,很大程度简化了分布式系统设计的难度。 也因此,CAP 定理是架构师所必须要掌握的内容,它影响着架构师对分布式系统的技术选型,技术决策。既然如此重要,接下来,我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔(Eric Brewer)在 2000 年的 ACM PODC 上提出的一个猜想,也因此被叫做布鲁尔定理。后来在 2002 年,麻省理工学院的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了 CAP 定理的证明,让它成为分布式系统领域公认的一个定理。 CAP 定理指出了,在一个跨区域网络连接,共享数据的分布式系统中,一致性(Consistency),可用性(Availability)和分区容错性(Partition Tolerance)

架构师都该懂的 CAP 定理

拈花ヽ惹草 提交于 2020-10-25 07:17:11
面对可能出现的网络延迟,不可预估的请求流量等情况,设计一个分布式系统,我们通常围绕系统高可用,数据一致性的目标去规划和实现,想要完全实现这个目标,却并非易事。由此,分布式系统领域诞生了一个基本定理,即 CAP 定理,用于指导分布式系统的设计,从系统高可用,数据一致性,网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来,让系统设计者只需根据业务场景特点,进行权衡设计适合业务场景的分区容错一致性模型即可,很大程度简化了分布式系统设计的难度。 也因此,CAP 定理是架构师所必须要掌握的内容,它影响着架构师对分布式系统的技术选型,技术决策。既然如此重要,接下来,我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔(Eric Brewer)在 2000 年的 ACM PODC 上提出的一个猜想,也因此被叫做布鲁尔定理。后来在 2002 年,麻省理工学院的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了 CAP 定理的证明,让它成为分布式系统领域公认的一个定理。 CAP 定理指出了,在一个跨区域网络连接,共享数据的分布式系统中,一致性(Consistency),可用性(Availability)和分区容错性(Partition Tolerance)