Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
【转载】关于Kubernetes v1.6的etcd使用 – zoues

LOADING

Follow me

【转载】关于Kubernetes v1.6的etcd使用
五月 26, 2017|DockerPaaS

【转载】关于Kubernetes v1.6的etcd使用

【转载】关于Kubernetes v1.6的etcd使用

关于Kubernetes v1.6的etcd使用


在云原生应用世界中,etcd是Kubernetes控制平面的唯一一个状态组件。这对于一个管理员来说很简单,但Kubernetes 1.6发布了维护9s可靠性的过程。但是别害怕,我保证你被照顾到。

1

etcd 数据仓库格式: v2 or v3?

etcd 版本3.0.0 以上支持2个不同的数据仓库: v2 和 v3, 但你需要知道哪个版本你在使用,因为它影响你备份信息的能力。

在 Kubernetes 1.5里, 默认数据仓库格式是v2, 但如果明确设置,v3仍可以出现。然而在Kubernetes v1.6中, 默认数据仓库是etcd v3, 但你仍需要权衡哪种格式,因为包围etcd的有多种组件。

举例来说,Calico, Canal, 和Flannel 可以只写入数据到etcd v2 数据仓库,所以将他们的etcd 数据与一个正在使用etcd v3的Kubernetes组合将使维护etcd的工作变得复杂。

用户盲目升级Kubernetes V1.5到V1.6时,可发现一个情况。(只是一个原因,重要的是总是阅读发行说明!) Kubernetes v1.6更改默认EtCd后端从V2 到V3,所以确保在你开始之前,手动迁移到EtCd V3。这样,可以保证数据的一致性,但这就要求关闭所有kube-apiservers。

如果你不想迁移,你可以设置kube-apiserver返回V2 EtCd,用下列选项:


–storage-backend=etcd2


 

2

备份etcd


Kubernetes所有的配置数据存储在etcd,所以在不可挽回的灾难事件时,操作员可以使用etcd备份来恢复所有数据。etcd定期自行创建快照,每日备份存储在分离的主机上是Kubernetes用于灾难恢复的一个很好的策略。

备份方式

针对etcd v2和v3,有多种不同备份方式,每种方式有它自己的优缺点。V3备份更干净并包括一个单一的压缩文件,但它有一个重大缺点:它不能备份或恢复v2数据。

这意味着如果你只有etcd v3 数据(如,如果你的网络插件不消耗etcd),你可以使用v3 备份,但如果你有任何v2数据 –甚至它混合了v3数据 –你必须使用v2备份方式。

让我们看下这些方法。

关于Kubernetes v1.6的etcd使用
Etcd v2 backups

etcd v2 备份方式使用单WAL文件创建了一个目录结构。你可以不中断etcd集群运行情况下,在线执行一个备份。备份一个 etcd v2+v3 数据仓库,使用如下命令:


etcdctl backup –data-dir /var/lib/etcd/ –backup-dir /backupdir


你可以在这里找到恢复EtCd V2官方方法,但这里是基本步骤概述。具有挑战性的部分是在一次重建群集一个节点:

  • 停止所有主机的etcd。

  • 清洗所有主机的 /var/lib/etcd/member

  • 在第一个etcd主机,拷贝备份到/var/lib/etcd/member

  • 在第一个etcd主机,使用force-new-cluster启动etcd

  • 在第一个etcd主机,设置正确的PeerURL IP地址替代127.0.0.1.

  • 添加下一个主机到集群

  • 在下一个主机启动etcd ,使用initial-cluster 设置可见的 etcd 主机+ 自身

  • 重复5 和6 直到所有etcd节点加入

  • 正常重启etcd (使用已见的设置)


在下面脚本里,你可以看到这些步骤:

#!/bin/bash   -e

#   Change as necessary

RESTORE_PATH=${RESTORE_PATH:-/tmp/member} 

#Extract   node data from etcd config

source   /etc/etcd.env || source /etc/default/etcd

function   with_retries {

   local retries=3

   set -o pipefail

   for try in $(seq 1 $retries); do

${@}

[ $?   -eq 0 ] && break

     if [[ “$try” ==   “$retries” ]]; then 

     exit   1

    fi

     sleep 3

   done

   set +o pipefail

 } 

this_node=$ETCD_NAME

node_names=($(echo   $ETCD_INITIAL_CLUSTER | /  

  awk -F'[=,]’ ‘{for (i=1;i<=NF;i+=2) {   print $i }}’))

node_endpoints=($(echo   $ETCD_INITIAL_CLUSTER | /  

  awk -F'[=,]’ ‘{for (i=2;i<=NF;i+=2) {   print $i }}’))

node_ips=($(echo   $ETCD_INITIAL_CLUSTER | /  

  awk -F’://|:[0-9]’ ‘{for   (i=2;i<=NF;i+=2) { print $i }}’))

     num_nodes=${#node_names[@]} 

# Stop   and purge etcd data

for i   in `seq 0 $((num_nodes – 1))`; do

  ssh ${node_ips[$i]} sudo service etcd   stop

  ssh ${node_ips[$i]} sudo docker rm -f   ${node_names[$i]} /     || : # Kargo   specific

  ssh ${node_ips[$i]} sudo rm -rf   /var/lib/etcd/member

 done

#   Restore on first node

 if [[ “$this_node” ==   ${node_names[0]} ]]; then

   sudo   cp -R $RESTORE_PATH /var/lib/etcd/

 else

   rsync   -vaz -e “ssh” –rsync-path=”sudo rsync” /

     “$RESTORE_PATH”   ${node_ips[0]}:/var/lib/etcd/

 fi

  ssh ${node_ips[0]} “sudo etcd   –force-new-cluster 2> /

  /tmp/etcd-restore.log” &

  echo “Sleeping 5s to wait for etcd   up”

 sleep 5

 # Fix member endpoint on first node

 member_id=$(with_retries ssh ${node_ips[0]}   /

  ETCDCTL_ENDPOINTS=https://localhost:2379 /

  etcdctl member list | cut -d’:’ -f1)

 ssh ${node_ips[0]}   ETCDCTL_ENDPOINTS=https://localhost:2379 /

   etcdctl member update $member_id   ${node_endpoints[0]}

echo   “Waiting for etcd to reconfigure peer URL”

 sleep 4

  # Add other nodes   initial_cluster=”${node_names[0]}=${node_endpoints[0]}”

 for i in `seq 1 $((num_nodes -1))`; do

  echo “Adding node   ${node_names[$i]} to ETCD cluster…”

  initial_cluster=/

     “$initial_cluster,${node_names[$i]}=${node_endpoints[$i]}”

   with_retries ssh ${node_ips[0]} /

    ETCDCTL_ENDPOINTS=https://localhost:2379   /

    etcdctl member add ${node_names[$i]}   ${node_endpoints[$i]}

  ssh ${node_ips[$i]} /

    “sudo etcd   –initial-cluster=”$initial_cluster” &>/dev/null” &

   sleep 5

  with_retries ssh ${node_ips[0]} /

ETCDCTL_ENDPOINTS=https://localhost:2379   etcdctl member list

done

  echo “Restarting etcd on all   nodes”

 for i in `seq 0 $((num_nodes -1))`; do

   ssh ${node_ips[$i]} sudo service etcd   restart

 done

  sleep 5

 echo “Verifying cluster health”

 with_retries ssh ${node_ips[0]} /

  ETCDCTL_ENDPOINTS=https://localhost:2379   etcdctl cluster-health

关于Kubernetes v1.6的etcd使用
Etcd v3 备份

该etcd V3备份创建一个单压缩文件。记住,它不能用来备份EtCd V2数据,所以要小心使用此方法。要创建V3备份,请运行该命令:

ETCDCTL_API=3   etcdctl snapshot save /backupdir

对于船舶V3官方程序恢复记录在这里,但你可以看到,一般的过程是比在V2 V3恢复过程更简单;能够重建集群没有颗粒的步骤。

所需步骤如下:

  • 在所有主机点关闭etcd

  • 清洗所有主机节点的 /var/lib/etcd/member

  • 拷贝备份文件到每个etcd 主机

  • 源 /etc/default/etcd ,并运行下面命令:


ETCDCTL_API=3   etcdctl snapshot restore BACKUP_FILE / –name $ETCD_NAME–initial-cluster   “$ETCD_INITIAL_CLUSTER” / –initial-cluster-token   “$ETCD_INITIAL_CLUSTER_TOKEN” / –initial-advertise-peer-urls   $ETCD_INITIAL_ADVERTISE_PEER_URLS / –data-dir $ETCD_DATA_DIR

3

调试etcd

因为etcd是用来存储Kubernetes的配置信息,其性能对集群的有效性能很关键。幸运的是,在不同部署情况下,etcd可以调试到更好的状态。所有的写操作都要求etcd节点之间的同步,这将有以下功能要求:

  • etcd 需要快速访问磁盘

  • etcd 需要低延迟连接到其他etcd节点

  • 写入数据到磁盘时,etcd 需要在所有etcd节点间同步数据


为满足需求,以下建议较有用:

  • 当磁盘空间密集型服务(如Ceph) etcd 仓库不应放置在同一磁盘

  • etcd 节点不应分布在数据中心

  • etcd 节点的数字应该是 3; 奇数可以阻止“脑裂”问题,但是超过3个对性能有拖累

默认etcd设置对低磁盘I/O的测试环境中是不理想的。因此,设置以下值:

ETCD_ELECTION_TIMEOUT=5000   #default 1000ms ETCD_HEARTBEAT_INTERVAL=250 #default 100ms

请注意,提高这些值在读/写性能方面有负面影响。它也为集群选举创建了时间惩罚,因为系统需要更长的时间来发现一些错误的事情。然而如果这些值太低,在经常有不良的网络或磁盘延迟情况下,群集将假设有一个问题,并经常执行重新选举。

4

Etcd故障处理

这是我们在etcd遇到的一些问题和解决方案。

问题

解决方案

我的恢复失败并且在etcd日志中看到“etcdmain:   database file (/var/lib/etcd/member/snap/db) of the backend is missing”

该etcd V2备份时,etcd在写快照文件。此备份文件不可用。唯一的解决方案是从另一个备份文件恢复。

为什么   etcd 不监听端口2379?

有几个可能的原因。首先,确保etcd服务正在运行。其次,检查每个主机的etcd服务日志上,是否有选举和/或仲裁问题。至少有51%的集群必须在线,以便任何数据被读取或写入,以防止脑裂的问题,这样你就不会发现情况,不同的数据写入集群。这意味着3节点群集必须有至少2个功能节点。

为什么etcd 实施这么多重新选举?

努力提升ETCD_ELECTION_TIMEOUT和ETCD_HEARTBEAT_INTERVAL.另外,试图减少主机上的负载量。你可以在这里发现更多信息。

UMCloud(上海优铭云计算有限公司)是一家中方控股的合资云计算公司,两大股东分别是中国顶尖的中立公有云服务商UCloud和全球排名第一的OpenStack云计算服务商Mirantis。公司成立于2016年,专注于私有云产品方案与服务、存储产品、Mirantis OpenStack培训等业务。 关于Kubernetes v1.6的etcd使用

       了解更多资讯  关注官方微信

no comments
Share