etcd

Kubernetes使用etcd来存储集群的实时运行数据（如节点状态信息），而其它pod都是无状态的、可以根据负载调度，在多个节点（node）间进行漂移。etcd本身是可以部署为无中心的多节点互备集群，从而消除整个集群的单一故障点。在kubeadm的缺省部署下，只在master上运行一个etcd实例（etcd-xxx），可以使用 kubectl get pod -n kube-system 查看运行状态。 参考： Kubernetes集群的主节点备份与恢复 1、查看etcd服务容器信息 下面我们来探索一下kubernetes的etcd实例到底是如何实现和管理的。在kubernetes的master节点上输入： kubectl describe pod/etcd-podc01 -n kube-system > etcd.txt 输出如下： Name: etcd-podc01 Namespace: kube-system Priority: 2000000000 PriorityClassName: system-cluster-critical Node: podc01/10.1.1.181 Start Time: Mon, 03 Dec 2018 10:42:05 +0800 Labels: component=etcd tier=control-plane Annotations

kubelet是Kubernetes中的核心组件，需要在每一个节点安装，也是kubernetes集群启动的第一个服务。kubelet的参数存放在多个目录，修改时如果不完整就会导致各种错误，下面我们kubelet的参数存放位置和配置方法一探究竟。 在Ubuntu18.04上kubelet是使用宿主机的systemd来启动的，目前kubernetes 1.12.3为止都还没有将其容器化。 kubelet的配置参数存放在三个不同的目录： /etc/kubernetes，kubenetes主目录，其中kubelet.conf包括apiserver连接参数和连接证书。 /lib/systemd/system/kubelet.service，kubelet服务的配置文件。 /var/lib/kubelet，kubelet的数据目录。 kubelet主数据目录参数 位于/var/lib/kubelet，包含本机由kubelet管理的所有资源。 supermap@podc01:/var/lib/kubelet$ tree . ├── config.yaml ├── cpu_manager_state ├── device-plugins │ ├── DEPRECATION │ ├── kubelet_internal_checkpoint │ └── kubelet.sock ├──

通常安装模式下（如使用kubeadm）的Kubernetes集群，主节点（Master）只有一个，而且集群数据存储服务etcd也只运行了一个实例。如果遇到极端情况（如整机故障、主硬盘损坏、数据误删除等）导致 master节点无法访问，则整个集群都将无法访问或出现异常现象 。所以master节点机器性能要求不一定很高，但是稳定性是越高越好。 为了有备无患，对主节点需要做好备份。 Kubernetes master节点控制组件的备份及恢复包括：容器镜像，etcd数据库，主节点证书、配置参数、插件等部分。 一、etcd数据库备份 一般来说，如果master节点需要备份恢复，除了误操作和删除，很可能就是整个机器已出现了故障，故而可能需要同时进行etcd数据的恢复。 在恢复时，在待恢复机器上的机器名称和ip地址需要与崩溃前的主节点配置完全一样，因为这个配置写在etcd数据存储当中的。 etcd数据库备份的具体操作方法参见： Kubernetes的etcd探秘-状态数据备份 二、主节点数据备份 除了etcd数据库，主节点数据备份还包括下面三个部分： /etc/kubernetes/目录下的所有文件(证书，manifest文件) 用户主目录下 .kube/config文件(kubectl连接认证) /var/lib/kubelet/目录下所有文件(plugins容器连接认证) 目录结构参考：

Kubernetes的集群元数据都保存在etcd中，我们可以直接访问来查看数据。 1、查看etcd数据 kubeadm默认安装 方法如下： ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \ --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \ get /registry/deployments/default --prefix --keys-only 因为Kubernetes中的etcd 实例使用了https，需要指定证书等信息，即cacert/cert/key参数。 上面的参数是在使用kubeadm默认安装时，证书位于宿主机的/etc/kubernetes/pki目录下，在安装etcdctl-client后就可以使用上面的命令来访问了。 cfssl证书安装 使用cfssl证书安装的etcd集群，证书的目录可以自己定，证书格式是*.pem。方法如下： ETCDCTL_API=3 etcdctl --endpoints=https://[10.1.1.202]

Keepalived是一个用于虚拟IP自动切换的软件，可以在多个节点指定一个虚拟IP地址，遇到主节点故障时将该虚拟IP漂移到其它可用的节点，从而保障服务可以持续，用于k8s中master节点的服务IP（即kube-apiserver监听的地址）的容错。 注意 服务所依赖的环境需要在所有节点上预先配置好。 Keepalived仅对IP地址进行漂移，当前应用状态会丢失。 当前应用的状态和数据需要应用自身在多节点间进行同步。 在Ubuntu18.04 LTS 安装软件( http://www.keepalived.org/ )： sudo apt install keepalived 刚安装完，配置文件目录/etc/keepalived/是空的，把下面的内容保存为文件keepalived.conf和chk_k8s_master.sh，放到该目录下。 注意： 虚拟IP会占用一个物理网卡地址。通过配置文件指定。 使用 ifconfig查看网卡的de vice接口信息，选择其它服务不用的网卡用于虚拟IP。 因为keepalived会动态改变绑定网卡的IP地址，不要把其它服务绑定到该网卡端口和IP地址上。 虚拟 ip 绑定的网卡 interface enp0s31f6 配置文件 配置文件/etc/keepalived/keepalived.conf： ! Configuration File

今天对集群节点的操作系统一升级，很多服务都不能用了。 使用 kubectl version检查，发现是kubeadm自动升级到1.13.0了，但是kubelet服务还是1.12.3 。因为kubernetes 1.13的变化比较大，尤其是etcd使用了版本3的接口，必须对所有集群数据升级才能用，问题就出在这儿了。 目前升级整个集群到1.13 工作量比较大，暂时没有时间，还是需要继续使用1.12系列。准备将所有节点降级到原来的1.12.3版本，并且阻止以后的自动升级。 ansible 命令如下： echo "Install Kubernetes 1.12.3 & Hold the version." ansible all -f 8 -i hosts_ansible -m shell -a " \ apt install kubeadm=1.12.3-00 kubectl=1.12.3-00 kubelet=1.12.3-00 -y --allow-downgrades --allow-change-held-packages && \ echo 'kubeadm hold' | dpkg --set-selections && \ echo 'kubectl hold' | dpkg --set-selections && \ echo 'kubelet hold' | dpkg

0. Linux环境调整 2个VM， 192.168.1.157（docker2） 作为master, 192.168.1.158 (docker3)作为minon 1. 修改hostname /etc/hostname 192.168.1.157命名为docker2 192.168.1.158 命名为docker3 2. 修改hosts /etc/hosts 增加 192.168.1.157 docker2 docker2 192.168.1.158 docker3 docker3 1. 修改yum的repo 目录下/etc/yum.repos.d创建文件kubernetes.repo，内容如下： [kubernetes] name=Kubernetes baseurl=http://files.rm-rf.ca/rpms/kubelet/ enabled=1 gpgcheck=0 2. 安装docker和kubenetes yum install -y docker kubelet kubeadm kubectl kubernetes-cni 3. 修改docker的镜像来源 使用daocloud的加速器： curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://7f135bb1.m

版权声明：本文由turboxu原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/152 来源：腾云阁 https://www.qcloud.com/community Kubernetes作为容器编排生态圈中重要一员，是Google大规模容器管理系统borg的开源版本实现，吸收借鉴了google过去十年间在生产环境上所学到的经验与教训。 Kubernetes提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上.kubernetes是一个开放的容器调度管理平台，不限定任何一种言语，支持java/C++/go/python等各类应用程序 。 kubernetes是一个完备的分布式系统支持平台，支持多层安全防护、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具，包括开发、测试、部署、运维监控，一站式的完备的分布式系统开发和支撑平台。 一. 系统架构

本文为《持续演进的 Cloud Native》的一篇学习记录。 一、Redis 自带的集群功能（Redis Cluster） 优势： 1. 去中心化 元数据分布在所有节点，不会轻易丢失。 2. 部署简单 Redis 自带的 redis-cli 即可。 3. 性能高 因为不必通过代理。 劣势： 1. SDK 复杂 不是大问题。Lettuce 和 Spring Data Redis（底层也是 Lettuce）对它有很好支持。 2. 没有良好的界面管理 目前官方有个简单的界面管理。如果需要，可以定制修改或自研。 3. 不一致问题 在主从异步、重新选主的过程中，Redis 集群不保证强一致性。当发生网络分区的时候，如果主服务器恰好在少数节点，实际上有一个可以继续写入的时间窗口。当多数节点完成重新选主，而网络分区恢复之后，会覆盖旧的主服务器在这个时间窗口内所写的数据。 4. gossip 协议的性能问题 当节点很多时，gossip 协议的报文会占据比较大的带宽。 注：目前最新版的 Redis 自带集群已经可以在 NAT 后面工作了。 二、客户端模式 客户端做负载均衡，并且直连 Redis 节点。 用 etcd 等作为注册发现服务，可实现 Redis 节点的动态改变（增删节点，节点扩容）。 优势： 1. 数据分散 将数据分到多个节点，整体容量得到了提升。 当一个节点不可用时，只有 1/n

etcd是近几年比较火热的一个开源的、分布式的键值对数据存储系统，提供共享配置、服务的注册和发现，本文主要介绍etcd的安装和使用。 etcd etcd介绍 etcd 是使用Go语言开发的一个开源的、高可用的分布式key-value存储系统，可以用于配置共享和服务的注册和发现。 类似项目有zookeeper和consul。 etcd具有以下特点： 完全复制：集群中的每个节点都可以使用完整的存档 高可用性：Etcd可用于避免硬件的单点故障或网络问题 一致性：每次读取都会返回跨多主机的最新写入 简单：包括一个定义良好、面向用户的API（gRPC） 安全：实现了带有可选的客户端证书身份验证的自动化TLS 快速：每秒10000次写入的基准速度 可靠：使用Raft算法实现了强一致、高可用的服务存储目录 etcd应用场景 服务发现 服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。 配置中心 将一些配置信息放到 etcd 上进行集中管理。 这类场景的使用方式通常是这样：应用在启动的时候主动从 etcd 获取一次配置信息，同时，在 etcd 节点上注册一个 Watcher 并等待，以后每次配置有更新的时候，etcd