etcd

使用kubeadm安装Kubernetes Dlutzhangyi 2019-08-07 23:45:17 979 收藏 5 分类专栏： Kubernetes 版权 使用kubeadm安装Kubernetes 环境准备 基础配置 安装Docker 关闭防火墙 关闭SELinux 关闭swap 配置转发参数 配置Kubernetes阿里云源 安装Kubernetes相关组件 加载IPVS内核 安装Master节点 执行kubeadm init 失败 手动下载镜像 执行kubeadm init 配置网络 安装Node节点 下载镜像 添加Node节点 FAQ 执行kubeadm init显示kubelet not running 获取不到pods 参考 本次配置使用kubeadm安装Kubernetes，使用kubeadm init和kubeadm join两个命令可以很容易的初始化master节点和将node节点加入到master节点上。 环境准备 系统 版本 Kubernetes v1.15.1 Docker 18.06.1-ce Centos7 CentOS Linux release 7.1.1503 (Core) 节点 主机名 Roles 10.32.170.109 dx-ee-releng-webserver01 master 10.21.88.3 gh-ee-plus09

操作环境 rbac 划分（HA高可用双master部署实例） 本文穿插了ha 高可用部署的实例，当前章节设计的是ha部署双master 部署 内网ip 角色 安装软件 192.168.0.10 master01 etcd,kube-apiserver,kube-controller-manager,kube-scheduler 192.168.0.12 master02 etcd,kube-apiserver,kube-controller-manager,kube-scheduler 192.168.0.7 node01 docker,kubelet,kube-proxy,flannel 192.168.0.8 node02 docker,kubelet,kube-proxy,flannel 192.168.0.4 slb master etcd，nginx 192.168.0.9 192.168.0.200 keepalived上的VIP 注意 flannel可以只安装node上，flannel只是跨机器宿主机和容器通讯使用 docker可以只安装node上，master上可以不安装 etcd 键值对的数据库，是独立三台机器。不要复用。 192.168.0.200是keepalived上的vip 自签SSL证书 k8s安装包下载 https://github.com

在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户， 这些突发的无法预先感知的热key都是系统潜在的巨大风险。 风险是什么呢？主要是数据层，其次是服务层。 热key对数据层的冲击显而易见，譬如数据存放在redis或者MySQL中，以redis为例，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都从该分片获取它的数据。由于redis性能还不错，再加上集群模式，每秒我们假设它能支撑20万次读取，这足以支持大部分的日常使用了。但是，以京东为例的这些头部互联网公司，动辄某个爆品，会瞬间引入每秒上百万甚至数百万的请求，当然流量多数会在几秒内就消失。但就是这短短的几秒的热key，就会瞬间造成其所在redis分片集群瘫痪。原因也很简单，redis作为一个单线程的结构，所有的请求到来后都会去排队，当请求量远大于自身处理能力时，后面的请求会陷入等待、超时。由于该redis分片完全被这个key的请求给打满，导致该分片上所有其他数据操作都无法继续提供服务，也就是热key不仅仅影响自己，还会影响和它合租的数据。很显然，在这个极短的时间窗口内，我们是无法快速扩容10倍以上redis来支撑这个热点的。虽然redis已经很优秀，但是它的内心是这样的：

在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户， 这些突发的无法预先感知的热key都是系统潜在的巨大风险。 风险是什么呢？主要是数据层，其次是服务层。 热key对数据层的冲击显而易见，譬如数据存放在redis或者MySQL中，以redis为例，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都从该分片获取它的数据。由于redis性能还不错，再加上集群模式，每秒我们假设它能支撑20万次读取，这足以支持大部分的日常使用了。但是，以京东为例的这些头部互联网公司，动辄某个爆品，会瞬间引入每秒上百万甚至数百万的请求，当然流量多数会在几秒内就消失。但就是这短短的几秒的热key，就会瞬间造成其所在redis分片集群瘫痪。原因也很简单，redis作为一个单线程的结构，所有的请求到来后都会去排队，当请求量远大于自身处理能力时，后面的请求会陷入等待、超时。由于该redis分片完全被这个key的请求给打满，导致该分片上所有其他数据操作都无法继续提供服务，也就是热key不仅仅影响自己，还会影响和它合租的数据。很显然，在这个极短的时间窗口内，我们是无法快速扩容10倍以上redis来支撑这个热点的。虽然redis已经很优秀，但是它的内心是这样的：

由于业务需要，近期在研究k8s，故就需要先部署一套。我通过官方文档来部署发现还是有一些坑，故整理了部署中遇到的问题做个记录。本文章主要介绍了在centos7环境下k8s 1.8.2+dashboard+metrics server+ingress的部署。 系统环境 1，k8s的版本为1.8.2 2，docker ce的版本为19.03.8-3 3，五台主机操作系统版本为centos7，kernel版本3.10.0-957 4，使用五台主机部署，机器列表 172.18.2.175 master1 172.18.2.180 master2 172.18.2.181 master3 172.18.2.186 work1 172.18.2.187 work2 172.18.2.182 apiserver-lb 部署HA架构 1，etcd是使用Go语言开发的一个开源的、高可用的强一致性分布式key-value存储系统，可以用于配置共享和服务的注册和发现集群，每个节点都可以提供服务。 2，kubernetes系统组件间只能通过API服务器通信，它们之间不会直接通信，API服务器是和etcd通信的唯一组件。 其他组件不会直接和etcd通信，需要通过API服务器来修改集群状态。 3，controller-manager和scheduler监听API服务器变化，如果API服务器有更新则进行对应的操作

在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户， 这些突发的无法预先感知的热key都是系统潜在的巨大风险。 风险是什么呢？主要是数据层，其次是服务层。 热key对数据层的冲击显而易见，譬如数据存放在redis或者MySQL中，以redis为例，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都从该分片获取它的数据。由于redis性能还不错，再加上集群模式，每秒我们假设它能支撑20万次读取，这足以支持大部分的日常使用了。但是，以京东为例的这些头部互联网公司，动辄某个爆品，会瞬间引入每秒上百万甚至数百万的请求，当然流量多数会在几秒内就消失。但就是这短短的几秒的热key，就会瞬间造成其所在redis分片集群瘫痪。原因也很简单，redis作为一个单线程的结构，所有的请求到来后都会去排队，当请求量远大于自身处理能力时，后面的请求会陷入等待、超时。由于该redis分片完全被这个key的请求给打满，导致该分片上所有其他数据操作都无法继续提供服务，也就是热key不仅仅影响自己，还会影响和它合租的数据。很显然，在这个极短的时间窗口内，我们是无法快速扩容10倍以上redis来支撑这个热点的。虽然redis已经很优秀，但是它的内心是这样的：

逻辑：业务服务--->etcd服务，从而获取分布式锁 搞事：有人在etcd服务上跑任务，把CPU差点撑满 结果：业务服务有毛刺，获取锁超时，频繁报错 呵呵哒。 来源： oschina 链接： https://my.oschina.net/u/4385242/blog/4274191

作者：王悦 爱可生研发团队成员，负责数据库管理平台相关项目的开发和故障排查，好奇 MySQL 技术原理及各类数据库实现方案。 本文来源：转载自公众号-图解 MySQL *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 注：阅读本文需要了解 pod，controller，service 等一些 kubernetes 的基本概念。 什么是 kubernetes？有了容器技术后为什么还需要 kubernetes？ 容器凭借其良好的移植性，敏捷性和革命性的打包方式迅速成为云服务的新基础设施。但 Docker 毕竟只是 “container runtime”，我们需要一个编排框架作为系统核心来串联开发、测试、部署、运维等整个软件生命周期。kubernetes 就提供这样一个框架，提供大量容器的部署、编排、管理的能力。 如果将 MySQL 部署在 kubernetes 会有哪些挑战？带来了什么收益？ 虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。 1、业务流量入口的配置方式 传统虚拟机环境下，我们通过虚 IP 的方式

前言 作为架构师来说，Apache Dubbo就是微服务领域中的佼佼者，为大家提供了多少便利，省了多少时间来熬夜掉头发，它的给大家的便利咱暂且不谈。咱今天就来谈谈，对于想进阿里的人来说，Dubbo是你必须掌握的框架。 因为Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 那作为想进阿里的程序员们，咱们该怎么来学习dubbo这个优秀的框架呢？这本技术文档送给大家来学习。 内容简介 本文首先介绍Dubbo的简史、后续的规划和整体架构大图; 接着介绍Dubbo环境配置,并基于Dubbo开发第一款应用程序; 然后介绍Dubbo内置的常用注册中心的实现原理，Dubbo扩展点加载的原理和实现，Dubbo的启动、服务暴露、服务消费和优雅停机的机制，Dubbo中RPC协议细节、编解码和服务调用实现原理，Dubbo集群容错、路由和负载均衡机制，Dubbo的扩展点相关知识，Dubbo高级特性的实现和原理，Dubbo 常用的Filter 的实现原理，Dubbo 中新增etcd3注册中心的实战内容和Dubbo服务治理平台的相关知识; 最后介绍Dubbo未来生态和DubboMesh的相关知识。 本文总共分为13章，主要介绍如下： 第1章主要介绍Dubbo的简史、后续的规划和整体架构大图。

一、 Kubernetes 简介 1、 由 google 公司开发， google 有 10 年容器化基础架构经验，自身的 borg 容器在公司内部使用，对外开源的是 Kubernetes ，由 go 语言开发，基于 http 协议的 C/S 架构， 是一种资源管理器 2、 特点 （1） go 语言为静态编译性语言，因此 k8s 特点之一轻量级：消耗资源小 （2） 开源 （3） 弹性伸缩 （4） 负载均衡： ipvs 二、 组件说明 1、 K8S 架构 2 、 MASTER 节点 （ 1 ） scheduler ：任务发起角色，选择合适的节点进行分配任务，它将任务交给 api server ， api server 将请求写入 etcd ，它并不会与 etcd 直接交互 （ 2 ） replication controller manager ： rc ，副本管理器，根据设置的 pod 数，使整个 k8s 一直保持这个 pod 数 （ 3 ） api server ：一切服务访问的入口，为避免 api server 过于繁忙，各服务组件在本地生成一定的缓存，同样的访问需求读取缓存 （ 4 ） etcd ：键值对数据库，存储 K8S 的参数信息，是一种可信赖的分布式存储服务，有自己的集群化方案，扩容方便，实现了 k8s 整个框架的持久化方案。 V2 将数据写入内存， V3