etcd

目录 1、生产环境k8s平台架构 2、官方提供三种部署方式 3、服务器规划 4、系统初始化 5、Etcd集群部署 5.1、安装cfssl工具 5.2、生成etcd证书 5.2.1 创建用来生成 CA 文件的 JSON 配置文件 5.2.2 创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件 5.2.3 生成CA证书（ca.pem）和密钥（ca-key.pem） 5.2.4 创建 etcd 证书签名请求 5.2.5 生成etcd证书和私钥 5.3、部署etcd 5.3.1 etcd二进制包 5.3.2 设置etcd配置文件 5.3.3 创建etcd系统服务 5.3.4 拷贝证书 5.3.5 拷贝配置到其他节点并修改配置 5.3.6 启动并检查 6、部署Master组件 6.1 生成证书 6.2 创建TLSBootstrapping Token 6.3 准备二进制包 6.4 部署kube-apiserver 6.5 部署controller-manager 6.6 部署kube-scheduler 6.6 给kubelet-bootstrap授权 6.7 检查集群状态 7、部署Node组件 7.1、安装docker 7.2、准备二进制包 7.3、拷贝证书到node 7.4、部署kubelet 7.5、部署kube-proxy 7.6、部署另外一个node 7.7

Kubernetes V1.15 二进制部署集群 分类: Web应用 , 敏捷开发 , 容器/虚拟化 , 玩转Linux undefined 1. 架构篇 1.1 kubernetes 架构说明 1.2 Flannel网络架构图 集群功能各模块功能描述： Master节点： Master节点上面主要由四个模块组成，APIServer，schedule,controller-manager,etcd APIServer: APIServer负责对外提供RESTful的kubernetes API的服务，它是系统管理指令的统一接口，任何对资源的增删该查都要交给APIServer处理后再交给etcd，如图，kubectl(kubernetes提供的客户端工具，该工具内部是对kubernetes API的调用）是直接和APIServer交互的。 schedule: schedule负责调度Pod到合适的Node上，如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定。 kubernetes目前提供了调度算法，同样也保留了接口。用户根据自己的需求定义自己的调度算法。 controller manager: 如果APIServer做的是前台的工作的话，那么controller manager就是负责后台的

我是先对docker初步到进阶的了解学习，常用的命令，基本的容器构建和docker原理概念学习完之后，步入k8s。即使这样，刚看k8s官方文档时，其设计理念、组件构成以及生态需要了解掌握的知识不在少数。为此，花了几天时间在官方文档&个人博客上做了上述方面初步了解，较为直观的便可分为两方面： master: API server Controller Manager Scheduler Etcd node: kublet kube-proxy pod Kubernetes集群组件: etcd 一个高可用的K/V键值对存储和服务发现系统 flannel 实现夸主机的容器网络的通信 kube-apiserver 提供kubernetes集群的API调用 kube-controller-manager 确保集群服务 kube-scheduler 调度容器，分配到Node kubelet 在Node节点上按照配置文件中定义的容器规格启动容器 kube-proxy 提供网络代理服务 这些是在安装过程中直接接触的组件，了解其用途和原理会更胸有成竹吧。 若没有docker基础，应优先学习docker，在构建k8s时更易切解决碰到的问题。 搭建过程 官网给出的搭建流程不是很满意，会出问题，环境不同异常不同，排查起来需要用时间填坑；此外也有大量开发者给出的个人经验很有借鉴意义但也是有漏洞，或不详尽

目录 一、看图说K8S 二、K8S的概念和术语 三、K8S集群组件 1、Master组件 2、Node组件 3、核心附件 四、K8S的网络模型 五、Kubernetes的核心对象详解 1、Pod资源对象 2、Controller 3、Service 一、看图说K8S 先从一张大图来观看一下K8S是如何运作的，再具体去细化K8S的概念、组件以及网络模型。 从上图，我们可以看到K8S组件和逻辑及其复杂，但是这并不可怕，我们从宏观上先了解K8S是怎么用的，再进行庖丁解牛。从上图我们可以看出： Kubernetes集群主要由Master和Node两类节点组成 Master的组件包括：apiserver、controller-manager、scheduler和etcd等几个组件，其中apiserver是整个集群的网关。 Node主要由kubelet、kube-proxy、docker引擎等组件组成。kubelet是K8S集群的工作与节点上的代理组件。 一个完整的K8S集群，还包括CoreDNS、Prometheus（或HeapSter）、Dashboard、Ingress Controller等几个附加组件。其中cAdivsor组件作用于各个节点（master和node节点）之上，用于收集及收集容器及节点的CPU、内存以及磁盘资源的利用率指标数据，这些统计数据由Heapster聚合后

01,集群环境 　　三个节点 master node1 node2 IP 192.168.0.81 192.168.0.82 192.168.0.83 环境 centos 7 centos 7 centos 7 02,配置软件 　　　　1,配置docker 包(三节点) 　　　　 wget -O /etc/yum.repos.d/docker-ce.repo https://mirrors.ustc.edu.cn/docker-ce/linux/centos/docker-ce.repo 　　　 2,配置k8s包(三节点) [root@admin ~]# cat /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ ##阿里云的连接 enabled=1 gpgcheck=0 repo_gpgcheck=0 gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

k8s概述 概述 Kubernetes 使你在数以千计的电脑节点上运行软件时就像所有这些节点是单个大节点一样。它将底层基础设施抽象，这样做同时简化了应用的开发、部署， 以及对开发和运维团队的管理。 Kubernetes 的核心功能 整个系统由一个主节点和若干个工作节点组成。开发者把一个应用列表提交到主节点， Kubemetes 会将它们部署到集群的工作节点。组件被部署在哪个节点对于开发者和系统管理员来说都不用关心。 Kubemetes 可以被当作集群的一个操作系统来看待 它降低了开发者不得不在他们的应用里实现一些和基础设施相关服务心智负担。他们现在依赖于Kubemetes 来提供这些服务，包括服务发现、扩容、负载均衡、自恢复，甚至领导者的选举。应用程序开发者因此能集中精力实现应用本身的功能而不用浪费时间思索怎样集成应用与基础设施。 Kubernetes 集群架构 在硬件级别， 一个Kubernetes 集群由很多节点组成，这些节点被分成以下两种类型 主节点，它承载着Kubernetes 控制和管理整个集群系统的控制面板 工作节点，它们运行用户实际部署的应用 控制面板 控制面板用于控制集群并使它工作。它包含多个组件，组件可以运行在单个主节点上或者通过副本分别部署在多个主节点以确保高可用性。 Kubernetes API 服务器，你和其他控制面板组件都要和它通信；提供了 HTTP

作者 | 阿里云容器平台高级技术专家 曾凡松（逐灵） 本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中，在集群规模上遇到的典型问题以及对应的解决方案，内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强，这些关键的增强是阿里巴巴内部上万节点的 Kubernetes 集群能够平稳支撑 2019 年天猫 618 大促的关键所在。 背景 从阿里巴巴最早期的 AI 系统（2013）开始，集群管理系统经历了多轮的架构演进，到 2018 年全面的应用 Kubernetes ，这期间的故事是非常精彩的，有机会可以单独给大家做一个分享。这里忽略系统演进的过程，不去讨论为什么 Kubernetes 能够在社区和公司内部全面的胜出，而是将焦点关注到应用 Kubernetes 中会遇到什么样的问题，以及我们做了哪些关键的优化。 在阿里巴巴的生产环境中，容器化的应用超过了 10k 个，全网的容器在百万的级别，运行在十几万台宿主机上。支撑阿里巴巴核心电商业务的集群有十几个，最大的集群有几万的节点。在落地 Kubernetes 的过程中，在规模上面临了很大的挑战，比如如何将 Kubernetes 应用到超大规模的生产级别。 罗马不是一天就建成的，为了了解 Kubernetes 的性能瓶颈，我们结合阿里的生产集群现状，估算了在

一、建立集群 1、在每台机器上建立环境变量 TOKEN=token-01 CLUSTER_STATE=new NAME_1=machine-1 NAME_2=machine-2 NAME_3=machine-3 HOST_1=10.240.0.17 HOST_2=10.240.0.18 HOST_3=10.240.0.19 CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:23802、在每台机器上运行如下命令 # For machine 1 THIS_NAME=${NAME_1} THIS_IP=${HOST_1} etcd --data-dir=data.etcd --name ${THIS_NAME} \ --initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \ --advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \ --initial-cluster ${CLUSTER

export ETCDCTL_API=3 ENDPOINTS=localhost:2379 etcdctl --endpoints=${ENDPOINTS} role add root etcdctl --endpoints=${ENDPOINTS} role grant-permission root readwrite foo etcdctl --endpoints=${ENDPOINTS} role get root etcdctl --endpoints=${ENDPOINTS} user add root etcdctl --endpoints=${ENDPOINTS} user grant-role root root etcdctl --endpoints=${ENDPOINTS} user get root etcdctl --endpoints=${ENDPOINTS} auth enable # now all client requests go through auth etcdctl --endpoints=${ENDPOINTS} --user=root:123 put foo bar etcdctl --endpoints=${ENDPOINTS} get foo etcdctl --endpoints=${ENDPOINTS} --user=root

# For each machine TOKEN=my-etcd-token-1 CLUSTER_STATE=new NAME_1=etcd-node-1 NAME_2=etcd-node-2 NAME_3=etcd-node-3 HOST_1=10.240.0.13 HOST_2=10.240.0.14 HOST_3=10.240.0.15 CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380 # For node 1 THIS_NAME=${NAME_1} THIS_IP=${HOST_1} etcd --data-dir=data.etcd --name ${THIS_NAME} \ --initial-advertise-peer-urls http://${THIS_IP}:2380 \ --listen-peer-urls http://${THIS_IP}:2380 \ --advertise-client-urls http://${THIS_IP}:2379 \ --listen-client-urls http://${THIS_IP}:2379 \ --initial-cluster ${CLUSTER} \