etcd

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

Kubernetes（通常称为"K8S"）是Google开源的容器集群管理系统。其设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。Kubernetes通常结合docker容器工具工作，并且整合多个运行着docker容器的主机集群，Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。Kubernetes是一个用于容器集群的自动化部署、扩容以及运维的开源平台。 通过Kubernetes, 可以快速有效地响应用户需求： -> 快速而有预期地部署应用； -> 极速地扩展你的应用； -> 无缝对接新的应用功能； -> 节省资源，优化硬件资源的使用； Kubernetes功能特性： -> 自动化容器部署与复制 -> 随时扩展或收缩容器规模 -> 组织容器成组，提供容器间的负载均衡 -> 快速更新及回滚容器版本 -> 提供弹性伸缩，如果某个容器失效就进行替换 Kubernetes重要组件： 1）Master组件 Master节点上面主要由四个模块组成：APIServer、scheduler、controller manager、etcd -> APIServer : 负责对外提供RESTful的Kubernetes API服务，它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd

前言 上篇 介绍了如何使用 etcd 实现服务发现，本篇将基于etcd的服务发现前提下，介绍如何实现gRPC客户端负载均衡。 gRPC负载均衡 gRPC官方文档提供了关于gRPC负载均衡方案 Load Balancing in gRPC ，此方案是为gRPC设计的，下面我们对此进行分析。 1、对每次调用进行负载均衡 gRPC中的负载平衡是以每次调用为基础，而不是以每个连接为基础。换句话说，即使所有的请求都来自一个客户端，我们仍希望它们在所有的服务器上实现负载平衡。 2、负载均衡的方法 集中式 （Proxy Model） 在服务消费者和服务提供者之间有一个独立的负载均衡（LB），通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy等实现。LB上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向LB发起请求，由LB以某种策略，比如轮询（Round-Robin）做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力，能自动摘除不健康的服务实例。 该方案主要问题：服务消费方、提供方之间增加了一级，有一定性能开销，请求量大时，效率较低。 可能有读者会认为集中式负载均衡存在这样的问题，一旦负载均衡服务挂掉，那整个系统将不能使用。 解决方案：可以对负载均衡服务进行DNS负载均衡，通过对一个域名设置多个IP地址

一 OpenShift特性 1.1 OpenShift概述 Red Hat OpenShijft Container Platform (OpenShift)是一个容器应用程序平台，它为开发人员和IT组织提供了一个云应用程序平台，用于在安全的、可伸缩的资源上部署新应用程序，而配置和管理开销最小。 OpenShift构建于Red Hat Enterprise Linux、Docker和Kubernetes之上，为当今的企业级应用程序提供了一个安全且可伸缩的多租户操作系统，同时还提供了集成的应用程序运行时和库。 OpenShift带来了健壮、灵活和可伸缩的特性。容器平台到客户数据中心，使组织能够实现满足安全性、隐私性、遵从性和治理需求的平台。不愿意管理自己的OpenShift集群的客户可以使用Red Hat提供的公共云平台OpenShift Online。 1.2 OpenShift特性 OpenShift容器平台和OpenShift Online都是基于OpenShift Origin开源软件项目的，该项目本身使用了许多其他开源项目，如Docker和Kubernetes。 应用程序作为容器运行，容器是单个操作系统内的隔离分区。容器提供了许多与虚拟机相同的好处，比如安全性、存储和网络隔离，同时需要的硬件资源要少得多，启动和终止也更快

目录 安装前的准备 最低系统要求 1. master最低要求 2. node最低要求 3. 磁盘要求 实验环境说明 预配置 1. 配置yum源 2. 安装基础环境依赖包 3. 安装docker 安装openshift 1. 安装openshift-ansible 2. 关闭selinux检查 3. 修改openshift-ansible代码中使用的yum源为国内源 4. 配置inventory 5. 执行部署 6. 卸载 7. 访问 注意事项及常见故障 注意事项 其他安装说明 常见错误 附录 安装前的准备 最低系统要求 1. master最低要求 最小4 vCPU 最小16 GB RAM /var/最小40 GB硬盘空间 /usr/local/bin/最小1 GB硬盘空间 临时目录最小1 GB硬盘空间 2. node最低要求 1 vCPU 最小8 GB RAM /var/最小15 GB硬盘空间 /usr/local/bin/最小1 GB硬盘空间 临时目录最小1 GB硬盘空间 3. 磁盘要求 /var/lib/etcd Less than 20 GB /var/lib/docker 50GB /var/lib/containers 50GB 这是openshift官方给出的最小要求，也是openshift-ansible检测环境时的最小要求，实际上，我们的实验环境满足不了最小要求

离线安装集群 参考 https://github.com/easzlab/kubeasz/blob/master/docs/setup/offline_install.md 离线文件准备 在一台能够访问互联网的服务器上执行： 下载工具脚本easzup，举例使用kubeasz版本2.2 export release=2.2.1 curl -C- -fLO --retry 3 https://github.com/easzlab/kubeasz/releases/download/${release}/easzup chmod +x ./easzup 使用工具脚本下载 默认下载最新推荐k8s/docker等版本，使用命令 ./easzup 查看工具脚本的帮助信息 # 举例使用 k8s 版本 v1.18.2，docker 19.03.5 ./easzup -D -d 19.03.5 -k v1.18.2 # 下载离线系统软件包 ./easzup -P 执行成功后，所有文件均已整理好放入目录/etc/ansible ，只要把该目录整体复制到任何离线的机器上，即可开始安装集群，离线文件包括： /etc/ansible 包含 kubeasz 版本为 ${release} 的发布代码 /etc/ansible/bin 包含 k8s/etcd/docker/cni 等二进制文件 /etc

2020年因为受到疫情的影响，各种电商直播纷纷涌入大家的视野，很多商家都通过直播的方式来售卖自己的产品。直播弹幕是直播系统的核心功能之一。如何迅速作出一个有很好扩展性的弹幕系统？如何应对业务迅速发展？相信很多工程师/架构师都有自己的想法。哔哩哔哩作为国内首屈一指的弹幕视频网站，今天我们就一起来看看他们是如何做的。 一对多直播系统开发，重点是这些 高并发实时弹幕是一种互动的体验。对于互动来说，考虑最多的地方就是：高稳定性、高可用性以及低延迟这三个方面。 高稳定性，为了保证互动的实时性，所以要求连接状态稳定。 高可用性，相当于提供一种备用方案，比如，互动时如果一台机器挂了，此时必须保证可以和另外一台机器连接，这样就从侧面解决了用户连接不中断的问题。 对于低延迟，弹幕的延迟周期控制在 1 秒以内，响应是比较快的，所以可以满足互动的需求。 一对多直播系统开发，GOIM 系统的优化之路 一、内存优化 内存优化主要分为以下三个方面： 1.一个消息一定只有一块内存 使用 Job 聚合消息，Comet 指针引用。 2.一个用户的内存尽量放到栈上 内存创建在对应的用户 Goroutine（Go 程）中。 3.内存由自己控制 主要是针对 Comet 模块所做的优化，可以查看模块中各个分配内存的地方，使用内存池。 二、模块优化 1.消息分发一定是并行的并且互不干扰 要保证到每一个 Comet

版本列表 kubeadm-config 的版本列表 命令 版本 kubeadm v1.11 v1alpha2 kubeadm v1.12 v1alpha3 kubeadm v1.13 or v1.14 v1beta1 kubeadm v1.15 v1beta2 基础知识 kubeadm-config 支持以下配置类型 apiVersion: kubeadm.k8s.io/v1beta2 kind: InitConfiguration apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration apiVersion: kubeadm.k8s.io/v1beta2 kind: JoinConfiguration init 和 join 的默认配置可以使用以下命令打印出来 kubeadm config print init-defaults kubeadm config print join-defaults Kubeadm init

前言 伴随微服务的推广，程序粒度的日趋小型化，服务数量逐渐增长，需要更多的关注服务本身的监控，服务上下游服务情况，以及相关数据源中间件的状态。我们需要更加多维度服务监控，能够对服务调用链路进行可视化、对目标服务调用时客户端与服务端的实时监控。在 Juno 监控中心，我们尝试解决这些问题。 为什么需要监控中心 在行业内越来越多的公司需要开发人员懂得服务器基础架构、操作系统、网络、语言特性、业务整体架构、面对线上问题快速分析快速定位、还包括服务性能调优，对这些方面的要求就是 Google 倡导的 SRE（站点可靠性工程师）。这项工作依赖于很多工具才能顺利完成，例如日志系统、发布系统、监控系统等等。 在斗鱼微服务管理系统 Juno，其中的监控中心的设计就是为协助开发人员进行高效的服务稳定性维护工作，完成对微服务系统的健康支持： 水位瓶颈，在斗鱼进行全链路压测，通过监控系统可以找到服务链路中的瓶颈，了解核心项目的具体水位； 故障预防，采用环比和同步数据进行服务健康波动分析，进行一定程度上的异常预防； 故障排查，线上故障快速定位，给出服务调用链路，从监控异常数据开始分析，排查影响范围，定位问题触发点。 主流产品差异性 只针对市场上的免费解决方案进行分析，目前分析的 Zabbix、Nagios 都比较偏向于基础运维监控工具。Juno 监控中心是 Grafana 和 Prometheus

一、介绍 Kubernetes 的作用是 用于管理容器化应用。 Kubernetes 的关键特性： 1、扩缩容 ： 通过简单的命令、用户界面或基于CPU的使用情况，能够对应用进行扩容和缩容。 2、 自愈能力：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。 3、 服务发现和负载均衡：开发者不需要使用额外的服务发现机制，就能够基于Kubernetes进行服务发现和负载均衡。 4、 自动发布和回滚：Kubernetes能够程序化的发布应用和相关的配置。如果发布有问题，Kubernetes将能够回归发生的变更。 5、 存储编排：自动挂接存储系统，这些存储系统可以来自于本地、公共云提供商（例如：GCP和AWS）、网络存储(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)。 二、整体架构 Kubernetes属于主从分布式架构，主要由 Master Node和Worker Node 组成，以及包括客户端命令行工具kubectl和其它附加项。 Master Node：作为控制节点，对集群进行调度管理；Master Node由API Server、Scheduler、Cluster State Store和Controller-Manger