etcd

作者 | 淮右、临石 **导读：**单 K8s 集群为用户提供了 Namespace 级别的隔离能力，理论上支持不超过 5K Node、15W Pod。多 K8s 集群则解决了单集群的资源隔离、故障隔离难题，打破可支持节点数、Pod 数的限制，但与此同时也带来了集群管理复杂度的上升；尤其在专有云场景中，K8s 工程师不可能像在公有云中一样快速触达客户环境，运维成本被进一步放大。因此如何低成本、高效率、自动化低管理多套 K8s 集群，成为业内普遍难题。 背景 多集群主要应用在如下场景： 1.产品本身需要多集群能力。产品的管控需要部署在 K8s 集群内，同时，该产品还需要提供 K8s 集群给用户使用，从故障隔离、稳定性、安全多重角度考虑，容器服务的管控和业务应该分别部署在不同的集群内； 2.用户在使用 K8s 的时候，也希望具备生产多套集群供不同业务使用，从而进行资源隔离、故障隔离； 3.同一用户可能需要多种类型集群的能力，以边缘计算 IOT 为例，它需要一个定制的边缘 K8s 集群，如果按照普通的独立 K8s 集群来创建，一方面会存在资源浪费，另一方面独立的集群为用户增加了运维的成本。 我们总结了运维 K8s 集群的难点，可以分为两部分： 难点 1：运维 K8s 集群的管控面 如何支持用户一键弹出新的 Kubernetes 集群？ 如何升级多个 K8s 集群的版本，当社区重大 CVE

作者：Sudip Sengupta 翻译： Bach （才云） 校对： bot （才云）、 星空下的文仔 （才云） 在 Kubernetes 中，创建、删除 Pod 可以说是最常见的任务之一。当我们进行滚动更新、扩展部署等等，都会创建 Pod。另外，在我们将节点标记为不可调度时，Pod 被驱逐后也会被删除并重新创建。 这些 Pod 的生命周期非常短暂，如果 Pod 还在响应请求的过程中，就被关闭了会怎么样？ 关闭前的请求是否已完成？ 接下来的请求又如何呢？ 在讨论删除 Pod 时会发生什么之前，我们需要知道在创建 Pod 时会发生什么。假设我们在集群中创建了以下 Pod： 我们将Pod YAML 定义提交给集群： 在输入命令后，kubectl 就会将 Pod 定义提交给 Kubernetes API。 K8sMeetup 在数据库中保存集群状态 API 接收并检查 Pod 定义，然后将其存储在 etcd 数据库中。另外，Pod 将被添加到调度程序的队列中。 调度程序会检查 Pod 定义，再收集有关工作负载的详细信息，例如 CPU 和内存请求，然后确定哪个节点最适合运行它。在调度程序结束后： 在 etcd 中的 Pod 会被标记为 Scheduled。 Pod 被分配到一个节点。 Pod 的状态会存储在 etcd 中。 但是 Pod 此时仍然是不存在的

系统初始化 集群规划 主机名 地址 组件 备注 k8s-m-1 10.66.10.26 ha+keeplaive kube-apiserver kube-controller_manager kube-scheduler vip :10.66.10.3 k8s-m-2 10.66.10.27 k8s-m-3 10.66.10.28 k8s-w-1 10.66.10.31 docker flannel kubelet kube-proxy k8s-w-2 10.66.10.32 k8s-w-3 10.66.10.33 ... ... k8s-w-10 10.66.10.40 主机名 设置永久主机名称，然后重新登录:（所有机器操作） hostnamectl set-hostname k8s-m-1 ... hostnamectl set-hostname k8s-w-10 设置的主机名保存在 /etc/hostname 文件中； 如果 DNS 不支持解析主机名称，则需要修改每台机器的 /etc/hosts 文件，添加主机名和 IP 的对应关系： cat >>/etc/hosts<<EOF 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost

一、管理k8s资源 1.管理k8s核心资源的三种基本方法 陈述式管理方法----主要依赖命令行cli工具进行管理 声明式管理方法--主要依赖统一资源配置清单（manifest）进行管理 GUI式管理方法--主要依赖图形化操作界面（web页面）进行管理 2.陈述式管理方法 2.1 管理namespace资源 ##查看名称空间 [root@kjdow7-21 ~]# kubectl get namespaces #或者 kubectl get ns NAME STATUS AGE default Active 4d18h kube-node-lease Active 4d18h kube-public Active 4d18h kube-system Active 4d18h ##查看名称空间内的资源 [root@kjdow7-21 ~]# kubectl get all -n default NAME READY STATUS RESTARTS AGE pod/nginx-ds-ssdtm 1/1 Running 1 2d18h pod/nginx-ds-xfsk4 1/1 Running 1 2d18h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 192.168.0.1

服务器信息 类型 服务器IP地址 备注 Ansible(2台) 172.24.78.21/22 K8S集群部署服务器，可以和在一起，需要配置在负载均衡上实现反向代理，dashboard的端口为8443 K8S Master(2台) 172.24.78.21/22 K8s控制端，通过一个VIP做主备高可用 Harbor(2台) 172.24.78.23/24 高可用镜像服务器 Etcd(最少3台) 172.24.78.25/26/27 保存k8s集群数据的服务器 Hproxy(2台) 172.24.78.28/29 高可用etcd代理服务器 Node节点(2-N台) 172.24.78.31/32/xxx 真正运行容器的服务器，高可用环境至少两台 主机信息 序号 类型 服务器IP 主机名 VIP 1 K8S Master1 172.24.78.21 master1.his.net 172.24.78.18 2 K8S Master2 172.24.78.22 master2.his.net 172.24.78.18 3 Harbor1 172.24.78.23 harbor1.his.net 4 Harbor2 172.24.78.24 harbor2.his.net 5 etcd节点1 172.24.78.25 etcd1.his.net 6 etcd节点2 172.24.78

ETCDCTL_API=3 etcdctl --endpoints 127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member list ETCDCTL_API=3 etcdctl --endpoints 127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove <node_id> 来源： oschina 链接： https://my.oschina.net/u/4370628/blog/4503446

简介： 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。-- 张翼（掌门教育创始人兼CEO） 联席作者：吴毅挺 任浩军 童子龙 郑重鸣谢：Nacos - 彦林，Spring Cloud Alibaba - 小马哥、洛夜，Nacos 社区 - 张龙（pader）、春少（chuntaojun） 掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos

一、管理k8s资源 1.管理k8s核心资源的三种基本方法 陈述式管理方法----主要依赖命令行cli工具进行管理 声明式管理方法--主要依赖统一资源配置清单（manifest）进行管理 GUI式管理方法--主要依赖图形化操作界面（web页面）进行管理 2.陈述式管理方法 2.1 管理namespace资源 ##查看名称空间 [root@kjdow7-21 ~]# kubectl get namespaces #或者 kubectl get ns NAME STATUS AGE default Active 4d18h kube-node-lease Active 4d18h kube-public Active 4d18h kube-system Active 4d18h ##查看名称空间内的资源 [root@kjdow7-21 ~]# kubectl get all -n default NAME READY STATUS RESTARTS AGE pod/nginx-ds-ssdtm 1/1 Running 1 2d18h pod/nginx-ds-xfsk4 1/1 Running 1 2d18h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 192.168.0.1

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

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ kubernetes 已经成为容器编排领域的王者，它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。 本文将带着大家快速了解 kubernetes ，了解我们谈论 kubernetes 都是在谈论什么。 kubernetes 架构 从宏观上来看 kubernetes 的整体架构，包括 Master、Node 以及 Etcd。 Master 即主节点，负责控制整个 kubernetes 集群。它包括 Api Server、Scheduler、Controller 等组成部分。它们都需要和 Etcd 进行交互以存储数据。 Api Server：主要提供资源操作的统一入口，这样就屏蔽了与 Etcd 的直接交互。功能包括安全、注册与发现等。 Scheduler：负责按照一定的调度规则将 Pod 调度到 Node 上。 Controller：资源控制中心，确保资源处于预期的工作状态。 Node 即工作节点，为整个集群提供计算力，是容器真正运行的地方，包括运行容器、kubelet、kube-proxy。 kubelet：主要工作包括管理容器的生命周期、结合 cAdvisor 进行监控、健康检查以及定期上报节点状态。 kube-proxy: