etcd

灾难恢复 　　etcd 被设计为能承受机器失败。etcd 集群自动从临时失败(例如，机器重启)中恢复，而且对于一个有 N 个成员的集群能容许 (N-1)/2 的持续失败。当一个成员持续失败时，不管是因为硬件失败或者磁盘损坏，它丢失到集群的访问。如果集群持续丢失超过 (N-1)/2 的成员，则它只能悲惨的失败，无可救药的失去法定人数(quorum)。一旦法定人数丢失，集群无法达到一致而因此无法继续接收更新。 为了从灾难失败中恢复，其中etcd v3 提供快照和修复工具来重建集群而不丢失 v3 键数据。 V2版api 备份数据： etcdctl backup --data- dir /home/etcd/ --backup- dir /home/etcd_backup 恢复： etcdctl -data- dir =/home/etcd_backup/ -force-new-cluster V3版api 在使用 API 3 时需要使用环境变量 ETCDCTL_API 明确指定。 在命令行设置： export ETCDCTL_API= 3 备份数据： etcdctl snapshot save " /root/$(date +%Y%m%d_%H%M%S)_snapshot.db " --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ Docker 虽好用，但面对强大的集群，成千上万的容器，突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了，先来了解一下 Kubernetes 的基本概念，后面再介绍实践，由浅入深步步为营。 关于 Kubernetes 的基本概念我们将会围绕如下七点展开： 一、Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现，是存在困难的编排、管理和调度问题。于是，我们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生！Kubernetes，名词源于希腊语，意为「舵手」或「飞行员」。Google 在 2014 年开源了 Kubernetes 项目，建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上，结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写，用 8 替代了 「ubernete」，下文我们将使用简称。 二、什么是 K8s ？ K8s 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。K8s 拥有一个庞大且快速增长的生态系统。K8s 的服务、支持和工具广泛可用。 通过 K8s 我们可以： 快速部署应用

用户不必备份容器中的所有内容，但在发生灾难时备份运行和管理容器的配置是很重要的。用户的容器基础设施需要某种类型的备份。Kubernetes和Docker在灾难之后不会自己构建。用户无需备份每个容器的运行状态，但是需要备份用于运行和管理容器的配置。 用户的容器基础设施需要某种类型的备份。Kubernetes和Docker在灾难之后不会自己构建。用户无需备份每个容器的运行状态，但是需要备份用于运行和管理容器的配置。 以下是用户需要备份的内容。 配置和所需状态信息 Dockerfile用于构建镱像以及这些文件的所有版本 从Dockerfile创建并用于运行每个容器的镜像 Kubernetes etcd和其他有关集群状态的K8s数据库 Deployments用于描述每个部署的YAML文件 容器创建或更改的持久数据 持久卷 数据库 Dockerfiles Docker容器从镜像运行，其镜像从Dockerfiles构建。正确的Docker配置将首先使用某种存储库(例如GitHub)作为所有Dockerfile的版本控制系统。不要使用从临时Dockerfile构建的临时镜像创建临时容器。所有Dockerfile都应存储在存储库中，如果当前版本存在问题，该存储库将允许用户提取这个Dockerfile的历史版本。 用户还应该具有存储与每个K8s部署关联的YAML文件的某种存储库

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 阿里妹导读：对象存储被广泛应用于互联网应用中，当我们打开手机观看视频、收听音乐、分享图片、浏览网页、淘宝购物时，背后的数据基本都是存在对象存储中。应用使用卡、打不开就和对象存储的可用性 SLA 有关，SLA 越高，应用体验越好。本文分享阿里云在对象存储 OSS(Open Storage Service) 的可用性 SLA (Service Level Agreement) 上的实践和技术沉淀。 一 概述 阿里云对象存储 OSS 通过十年积累的技术红利，长期在双十一淘宝应用如丝般顺滑体验需求的打磨下，2020 年 6 月将可用性 SLA 提升 10 倍，其中 OSS 标准型（同城冗余）存储，SLA 从 99.95% 提升到 99.995%，简单理解能支持 10 万张图片最多只有 5 个显示卡，下一章有详细解释。 二 如何度量 OSS 可用性 SLA 要想掌握 OSS 可用性 SLA，可以通过梳理业界可用性的来龙去脉，来理解背后的技术。 1 业界常见的可用性度量为年故障时长 业界对可用性的描述，通常采用年故障时长。比如，数据中心机房划分为不同等级，如 T1～T4 机房，它们的可用性指标如下所示： T1 机房：可用性 99.671%、年平均故障时间 28.8 小时 T2 机房：可用性

一、环境规划 1、架构拓扑图 2、主机规划 master 192.168.118.18 node01 192.168.118.19 node02 192.168.118.20 192.168.118.18即时master也是node 3、软件版本 [root@master ~]# cat /etc/redhat-release CentOS Linux release 7.8.2003 (Core) [root@master ~]# docker version Client: Version: 1.13.1 API version: 1.26 Package version: docker-1.13.1-161.git64e9980.el7_8.x86_64 Go version: go1.10.3 Git commit: 64e9980/1.13.1 Built: Tue Apr 28 14:43:01 2020 OS/Arch: linux/amd64 Server: Version: 1.13.1 API version: 1.26 (minimum version 1.12) Package version: docker-1.13.1-161.git64e9980.el7_8.x86_64 Go version: go1.10.3 Git commit: 64e9980

分享一下Rocky版本的OpenStack安装管理经验： OpenStack每半年左右更新一版，目前是版本是201808月发布的版本-R版(Rocky)，目前版本安装方法优化较好，不过依然是比较复杂 官方文档地址： https://docs.openstack.org/install-guide/openstack-services.html 本文主要分享控制节点的环境配置方法： ---------------- 完美的分割线 ------------------ 1.0.系统环境 1）生产测试应用的服务器最好是物理机，虚拟目前可以完成搭建测试体验 2）系统选择是目前的最新版本：CentOS Linux release 7.5.1804 (Core) 3）控制节点Controller ：192.168.1.81 计算节点Nova：192.168.1.82 1.1.配置域名解析 1）配置主机名 # 主机名设置好就不能修改，否则会出问题，控制节点和计算节点配置相同，且都需要配置 hostname openstack01.zuiyoujie.com hostname echo " openstack01.zuiyoujie.com " > /etc/ hostname cat /etc/hostname 2）配置主机名解析 vim /etc/ hosts ----------------

昨天 市面上有这么多语言为啥还需要开发Go这么个语言？ 07年的一天，几位谷歌的大牛在讨论用C++开发一些有关庞大的分布式集群的工作，非常繁琐但很核心，很是闹心，后来听说C++又要添加35项新特性。大牛听了很是不爽啊，于是讨论能否可开发一款新的语言，运行快、编译快、开发还快。于是几位列举了新语言的主要特性，并且借鉴现有语言众家之所长。说干就干，09年go语言就诞生了。以下是当年列举的主要特性 规范的语法（不需要符号表来解析） 垃圾回收（独有） 无头文件 明确的依赖 无循环依赖 常量只能是数字 int和int32是两种类型 字母大小写设置可见性（letter case sets visibility） 任何类型（type）都有方法（不是类型） 没有子类型继承（不是子类） 包级别初始化以及明确的初始化顺序 文件被编译到一个包里 包package-level globals presented in any order 没有数值类型转换（常量起辅助作用） 接口隐式实现（没有“implement”声明） 嵌入（不会提升到超类） 方法按照函数声明（没有特别的位置要求） 方法即函数 接口只有方法（没有数据） 方法通过名字匹配（而非类型） 没有构造函数和析构函数 postincrement（如++i）是状态，不是表达式 没有preincrement(i++)和predecrement

https://www.jianshu.com/p/7a41f0294f32 人生如逆旅，我亦如行人 本篇教程将大家Haproxy+Keepalived集群，主机规划可以参考我的这一篇文章 搭建高可用Kubernetes集群之etcd集群搭建篇（一） Keepalived简介 说到Keepalived，首先介绍一下什么是VRRP（Virtual Router Redundancy Protocol）协议，即虚拟器路由冗余协议，是为了解决局域网内默认网关单点失效的问题。 VRRP 将局域网内的一组路由器组成一个虚拟路由器组,每个路由器都有自己的局域网地址, 根据设置的优先级最高决定那个是master路由器。然后网关地址赋给该主路由器, 该主路由器定时发送VRRP报文向虚拟路由器组公布健康状况, 备份的路由器根据柏爱文判断Master路由器是否工作正常,从而决定是否要接替它. VRRP说白了就是实现IP地址漂移的，是一种容错协议。在下图中，Router A(10.100.10.1)、Router B(10.100.10.2)和Router C(10.100.10.3) 组成一个虚拟路由器。各虚拟路由器都有自己的IP地址。局域网内的主机将虚拟路由器设置为缺省网关。 Router A、Router B和Router C中优先级最高的那台路由器作为Master路由器,比如A，承担网关的功能

本文内容 本文致力于介绍K8s一些基础概念与串联部署应用的主体流程，使用Minikube实操 基础架构概念回顾 温故而知新，上一节 【K8S学习笔记】初识K8S 及架构组件 我们学习了K8s的发展历史、基础架构概念及用途，本节讲的内容建立在其上，有必要把之前的架构小节提出来回顾下： K8s架构分为控制平台(位于的Master节点)与执行节点Node 控制平台包含： kube-apiserver（访问入口，接收命令） etcd（KV数据库，保存集群状态与数据） kube-scheduler（监控节点状态，调度容器部署） kube-controller-manager（监控集群状态，控制节点、副本、端点、账户与令牌） cloud-controller-manager（控制与云交互的节点、路由、服务、数据卷） 执行节点包含： kubelet（监控与实际操作容器） kube-proxy（每个节点上运行的网络代理，维护网络转发规则，实现了Service） 容器运行时环境CRI（支持多种实现K8s CRI的容器技术） 接下来需要引入 Pod 与 Service 的概念，这也是在上一篇文章中未给出的 Pod、Service与Label概念 Pod概念与结构 Pod 是 K8s最重要的基本概念，官网给出概念：Pod是Kubernates可调度的最小的、可部署的单元。怎么理解呢？最简单的理解是

k8s实践系列的相关文件都在github： https://github.com/huangguisu/k8s.git etcd分布式键值存储系统，用于保持集群状态，比如Pod、Service等对象信息。因此我们在k8s集群安装之前，先把搭建好etcd集群。 一、ETCD简介 ​ etcd是由CoreOS团队发的一个分布式一致性的KV存储系统，可用于服务注册发现和共享配置，随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。 1、优点： etcd作为一个受到ZooKeeper与doozer启发而催生的项目，除了拥有与之类似的功能外，更专注于以下四点： 简单： 安装配置简单，而且提供了 HTTP API 进行交互，使用也很简单 安全： 支持 SSL 证书验证 快速： 根据官方提供的 benchmark 数据，单实例支持每秒 2k+ 读操作 可靠： 采用 raft 算法，实现分布式系统数据的可用性和一致性 2、使用场景 1、服务发现（Service Discovery）：