etcd運維操做

時間  2021-02-14
標籤 node 算法 數據庫 後端 api 安全 bash 網絡 app 性能 欄目 SQL 简体版
原文   原文鏈接

因爲etcd須要TLS認證，在master節點上有訪問etcd須要的證書，因此最好在master節點上進行操做。
Etcd各節點地址和證書路徑信息能夠查看kube-apiserver的啓動參數：ps -ef|grep kube-apiserver 啓動參數中都會有etcd的節點地址和證書路徑信息
Etcdctl命令依賴如下環境變量，操做前需先進行環境變量設置（需根據實際環境進行修改）node

export ENDPOINTS=https://192.168.0.1:2379,https://192.168.0.2:2379,https://192.168.0.3:2379
export CA_FILE=/etc/kubernetes/ssl/ca.pem
export CERT_FILE=/etc/etcd/ssl/etcd.pem
export KEY_FILE=/etc/etcd/ssl/etcd-key.pem

基本操做

列出節點成員

V2:
export ETCDCTL_API=2
etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE member list
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member list

查看節點的健康狀態

V2:
export ETCDCTL_API=2
etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE cluster-health
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE endpoint health

查看節點的狀態

V2:
無此命令
V3:
export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE endpoint status -w table

查看flannel配置信息

V2:
# export ETCDCTL_API=2
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls
/kubernetes
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes
/kubernetes/network
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes/network
/kubernetes/network/config
/kubernetes/network/subnets
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE get /kubernetes/network/config
{"Network":"172.1.0.0/16", "Subnetlen":24, "Backend": {"Type":"vxlan"}}
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE ls /kubernetes/network/subnets
/kubernetes/network/subnets/172.1.80.0-24
/kubernetes/network/subnets/172.1.44.0-24
/kubernetes/network/subnets/172.1.66.0-24
/kubernetes/network/subnets/172.1.89.0-24
/kubernetes/network/subnets/172.1.18.0-24
/kubernetes/network/subnets/172.1.42.0-24
/kubernetes/network/subnets/172.1.5.0-24
/kubernetes/network/subnets/172.1.68.0-24
/kubernetes/network/subnets/172.1.71.0-24
/kubernetes/network/subnets/172.1.57.0-24
/kubernetes/network/subnets/172.1.59.0-24
/kubernetes/network/subnets/172.1.9.0-24
/kubernetes/network/subnets/172.1.101.0-24
/kubernetes/network/subnets/172.1.29.0-24
# etcdctl --endpoints=$ENDPOINTS --cert-file $CERT_FILE --key-file $KEY_FILE --ca-file $CA_FILE get /kubernetes/network/subnets/172.1.29.0-24
{"PublicIP":"x.x.x.x","BackendType":"vxlan","BackendData":{"VtepMAC":"96:76:bc:31:b0:00"}}

經過以上步驟，能夠查看到flannel的配置子網和後端的配置信息，還能看到各節點flannel.1接口對應的mac和信息和節點IP信息算法

flannel在etcd中保存信息的路徑也能夠在flannel的配置文件中查看到，可經過cat /etc/flanneld/flanneld或ps -ef|grep flannel查看到數據庫

查看k8s集羣API資源信息

export ETCDCTL_API=3
#獲取全部的key值
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get / --prefix --keys-only
#查看pod信息
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get /registry/pods --prefix --keys-only
#查看service信息
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE get /registry/services/specs --prefix --keys-only
#以上路徑可根據須要進行修改

查看集羣告警信息

export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE alarm list

數據備份

備份一個節點的數據就能夠恢復，實踐中，爲了防止定時任務配置的節點異常沒有生成備份，建議多在幾個節點配置定時備份。備份示例腳本以下後端

export ETCDCTL_API=3
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save cluster1_1198_366_49k.db

集羣恢復

Etcd可以承受節點的短時間失效。當有節點短時間失效時，集羣可以自動恢復。當集羣的節點數爲N時，可以承受最大（N-1）/2的節點失效後自動恢復；若失效的節點數超過（N-1）/2，將會因爲沒法使得半數以上節點達成共識而形成整個集羣失效
爲了恢復失效的集羣，etcd提供了快照功能和恢復措施用於重建整個集羣而不會致使丟失數據api

獲取快照數據

恢復一個集羣首先須要從一個集羣節點獲取快照數據。快照能夠是經過etcdctl snapshot save從一個存活的節點進行備份或者直接從節點的etcd數據目錄複製member/snap/db文件。下面的命令是從一個存活的節點備份快照數據安全

ETCDCTL_API=3 etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save snapshot.db

恢復集羣

恢復集羣只須要一個快照db文件便可。使用etcdctl snapshot restore命令恢復集羣時，集羣會建立新的數據目錄，而且全部的member都必須使用同一個db文件進行恢復
恢復集羣時，可選擇性地對db文件的完整性進行校驗。若是db文件是經過etcdctl snapshot save命令保存獲得的，則db文件中會包含一個db文件完整性校驗的hash值，這個值可用於etcdctl snapshot restore該db文件時進行校驗；若是db文件是從節點的數據目錄直接複製過來的，則db文件不會包含這個hash值，在執行etcdctl snapshot restore指令時，須要加上--skip-hash-check選項
etcdctl snapshot restore操做會初始化新的節點數據目錄，而且使用新的配置信息，可是會保留快照中的原始key數據和值信息。以下示例命令恢復一個節點，恢復的數據目錄在/var/lib/etcd/infra4，目標集羣各個節點須要分別執行恢復命令bash

$ etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra4 
--data-dir=/var/lib/etcd/infra4 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23804

接下來使用恢復獲得的數據目錄啓動各個節點，如下示例命令恢復一個節點，同理，目標集羣的各個節點須要分別執行腳本進行啓動網絡

#!/bin/bash
node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra4
etcd 
--name=infra4 
--initial-advertise-peer-urls=https://$node4:23804 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node4:23804 
--listen-client-urls=https://$node4:23794 
--advertise-client-urls=https://$node4:23794 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

Etcd配置變動

Etcd集羣配置變動須要在集羣大多數節點功能正常的狀況下進行，而且強烈建議集羣的數量必須大於2，若是從一個節點數爲2的集羣中刪除一個節點時，將致使集羣不可用app

配置變動使用場景

  • 主機按照計劃進行維護，如硬件升級
  • 變動集羣大小
  • 更換一個出現故障的member
  • 集羣多數節點異常，須要重啓集羣

配置變動相關的操做

配置變動須要在集羣大多數（1/2以上）節點工做正常的狀況下進行，這是任何一種配置變動的先決條件。
對集羣作任何一種變動都必須按順序操做，不能亂序，例如：性能

  • 要更新一個節點的peerURLs，只執行一次更新操做
  • 要替換一個健康的節點成員，則先刪除舊的成員，再添加新的成員，而不能直接替換
  • 要將集羣的節點數從3擴大至5，則須要執行兩次增長節點的操做，而不能一次增長兩個節點
  • 要將集羣的節點數從5降至3，則須要執行兩次刪除節點的操做，而不能一次刪除兩個節點

更新一個節點

更新節點advertise client URLs

要更新某個節點的advertise client URLs，只須要在該節點的配置中更新advertise client URLs，而後重啓該節點的etcd，重啓後，該節點的etcd會以新的client URLs對外提供服務。節點的client URLs更新出現錯誤時，不會影響集羣的健康狀態

更新節點advertise peer URLs

要更新某個節點的advertise peer URLs，須要顯示的經過etcdctl的member命令更新peer-urls參數，而後重啓該節點。因爲節點peer URLs涉及到的的是集羣範圍的配置變動，操做不當會影響集羣的健康狀態，因此要規範操做

  • 首先經過etcdctl的member list命令獲取節點ID
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member list
6e3bd23ae5f1eae0: name=node2 peerURLs=http://localhost:23802 clientURLs=http://127.0.0.1:23792
924e2e83e93f2560: name=node3 peerURLs=http://localhost:23803 clientURLs=http://127.0.0.1:23793
a8266ecf031671f3: name=node1 peerURLs=http://localhost:23801 clientURLs=http://127.0.0.1:23791
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member update a8266ecf031671f3 --peer-urls=http://10.0.1.10:2380

Updated member with ID a8266ecf031671f3 in cluster
  • 修改etcd的peer urls參數，而後重啓etcd

刪除一個節點

假設要刪除的節點ID是a8266ecf031671f3，使用member remove命令移除節點

etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member remove a8266ecf031671f3

節點a8266ecf031671f3會自動中止並退出，並輸出以下日誌
etcd: this member has been permanently removed from the cluster. Exiting.
移除leader節點也是安全的，但在新的leader選舉出來前，集羣是不可用的

增長一個節點

增長一個節點分爲兩步：

  • 經過etcdctl member add指令將新的成員添加到集羣當中，告訴集羣新的成員信息，例如新成員的名字，peer urls
etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE member add infra3 --peer-urls=http://10.0.1.13:2380
輸出以下信息：
added member 9bf1b35fc7761a23 to cluster
ETCD_NAME="infra3"
ETCD_INITIAL_CLUSTER="infra0=[http://10.0.1.10:2380](http://10.0.1.10:2380/),infra1=[http://10.0.1.11:2380](http://10.0.1.11:2380/),infra2=[http://10.0.1.12:2380](http://10.0.1.12:2380/),infra3=[http://10.0.1.13:2380](http://10.0.1.13:2380/)"
ETCD_INITIAL_CLUSTER_STATE=existing

該命令已通知集羣新加入的節點信息，並打印出了新節點加入時須要配置的環境變量信息，新節點須要配置這些環境變量才能成功啓動

  • 使用新的集羣配置信息啓動新加入的成員
$ export ETCD_NAME="infra3"
$ export ETCD_INITIAL_CLUSTER=」infra0=http://10.0.1.10:2380, infra1=http://10.0.1.11:2380, infra2=http://10.0.1.12:2380, infra3=http://10.0.1.13:2380」
$ export ETCD_INITIAL_CLUSTER_STATE=existing
$ etcd --listen-client-urls http://10.0.1.13:2379 --advertise-client-urls http://10.0.1.13:2379 --listen-peer-urls http://10.0.1.13:2380 --initial-advertise-peer-urls http://10.0.1.13:2380 --initial-cluster="infra0=http:// 10.0.1.10:2380, infra1=http:// 10.0.1.11:2380, infra2=http:// 10.0.1.12:2380, infra3=http:// 10.0.1.13:2380" --data-dir %data_dir%

新節點啓動完成後，就會當即同步其餘的節點
注意，"initial-cluster"裏面必定要有新成員的peer地址，由於etcdctl執行完畢"etcdctl member add"後，etcd cluster就把這個還未存在的node算進quorum了，第二步必須準確完成
若是要新增多個節點時，最好是一次新增一個，而且須要確保新增的節點正常啓動且運行正常後在新增下一個節點。
若是是向只有一個節點的集羣新增節點，在執行member add命令後，新節點正常啓動並與已存在的節點創建鏈接以前，集羣不會繼續執行數據的提交工做，由於此時集羣在等待多數節點達成共識

新增節點可能遇到的error case

  • 新增節點在啓動時沒有將新節點的peer urls加入到啓動參數--initial-cluster參數中，則新節點會啓動失敗
etcd --name infra3 --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380  --initial-cluster-state existing
輸出信息以下：
etcdserver: assign ids error: the member count is unequal
exit 1
  • 新增節點啓動時，啓動參數中給了一個錯誤的peer urls。例如，將正確的地址10.0.1.13:2380誤寫爲10.0.1.14:2380
$ etcd --name infra4 --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra4=http://10.0.1.14:2380 --initial-cluster-state existing 
輸出信息以下  
etcdserver: assign ids error: unmatched member while checking PeerURLs   
exit 1

磁盤空間限額

Etcd的space quota能夠保證集羣已可靠的方式運行。若是不配置space quota，etcd的key存儲空間可能會過分的增加致使性能降低，甚至在超過磁盤的可用空間時，致使不可預期的行爲。若是任何一個節點的後端數據庫大小超過space quota時，etcd會產生一個集羣範圍的告警，使集羣進入一種維護狀態，在這種狀態下，集羣只接受key的讀取和刪除，只有在釋放了足夠的key值或者對數據庫進行碎片整理後，集羣才能進入正常工做狀態
經過如下啓動參數配置keyspace使用的空間限額

# set a very small 16MB quota
$ etcd --quota-backend-bytes=$((16*1024*1024))

與運行環境有關的faq

"apply entries took too long"

etcd集羣接受一個寫請求後，每一個etcd成員都須要把寫請求數據固化到cores/bbolt之中，整個過程不要超過50ms。若是超過100ms，則etcd就會打印此條log進行警告。一般狀況下是由於磁盤慢，好比磁盤競爭或者譬如虛擬塊磁盤這種爛設備。etcd暴露給Prometheus的metrics指標backendcommitduration_seconds就顯示了commit的瓶頸時間，這個指標低於25ms便可認爲服務正常，若是磁盤自己確實慢則設置一個etcd專用磁盤或者更換成SSD一般就能解決問題。
第二個緣由是CPU計算力不足。若是是經過監控系統發現CPU利用率確實很高，就應該把etcd移到更好的機器上，而後經過cgroups保證etcd進程獨享某些核的計算能力，或者提升etcd的priority。

"failed to send out heartbeat on time"

etcd使用了raft算法，leader會定時地給每一個follower發送心跳，若是leader連續兩個心跳時間沒有給follower發送心跳，etcd會打印這個log以給出告警。一般狀況下這個issue是disk運行過慢致使的，leader通常會在心跳包裏附帶一些metadata，leader須要先把這些數據固化到磁盤上，而後才能發送。寫磁盤過程可能要與其餘應用競爭，或者由於磁盤是一個虛擬的或者是SATA類型的致使運行過慢，此時只有更好更快磁盤硬件才能解決問題。etcd暴露給Prometheus的metrics指標walfsyncduration_seconds就顯示了wal日誌的平均花費時間，一般這個指標應低於10ms。
第二種緣由就是CPU計算能力不足。若是是經過監控系統發現CPU利用率確實很高，就應該把etcd移到更好的機器上，而後經過cgroups保證etcd進程獨享某些核的計算能力，或者提升etcd的priority。
第三種緣由就多是網速過慢。若是Prometheus顯示是網絡服務質量不行，譬如延遲過高或者丟包率太高，那就把etcd移到網絡不擁堵的狀況下就能解決問題。可是若是etcd是跨機房部署的，長延遲就不可避免了，那就須要根據機房間的RTT調整heartbeat-interval，而參數election-timeout則至少是heartbeat-interval的5倍。

"snapshotting is taking more than x seconds to finish ..."

etcd會把kv snapshot發送給一些比較慢的follow或者進行數據備份。慢的snapshot發送會拖慢系統的性能，其自身也會陷入一種活鎖狀態：在很慢地收完一個snapshot後尚未處理完，又由於過慢而接收新的snapshot。當發送一個snapshot超過30s而且在1Gbps(千兆)網絡環境下使用時間超過必定時間時，etcd就會打印這個日誌進行告警。

"request ignored (cluster ID mismatch)"

etcd cluster啓動的時候經過"initial-cluster-token"參數指定集羣的名稱。若是一個老集羣已經tear down，可是還有部分紅員活着，此時在老集羣之上又部署新的集羣以後，那些還活着的老成員會嘗試鏈接新集羣的各個成員，由於cluster token不一致新成員接收到請求後會報出這個warning。
避免這個錯誤的方法就是不要使用老集羣的地址。

etcd 對時間很依賴，因此集羣裏的節點時間必定要同步

etcd集羣出現unhealthy的節點處理

若是raft集羣中有處於unhealthy狀態的node，須要先把它剔除掉，而後才能進行替換操做。可是添加一個新的node是一件很是高風險的操做：若是一個3節點的etcd集羣有一個unhealthy node，此時沒有先把unhealthy node剔除掉，而新添加節點時可能因爲配置不當或者其餘緣由致使新的node添加失敗，則新集羣理論上node number爲4而當前quorum只可能達到2，失去consensus的集羣對任何操做都沒法達成共識。
若是按照正確的操做步驟，先剔除 unhealthy node，此時n爲2而quorum爲2，添加新節點後n爲 3，及時添加新節點失敗也不會致使集羣不可用。

etcd集羣實踐

集羣狀態查看

集羣的初始狀態如上圖，集羣已通過屢次反覆重啓，leader選舉已發生了1196次
向集羣寫入一次數據，RAFT INDEX會加1，RAFT TERM表示的是leader選舉的輪數，只有從新發生leader選舉，RAFT TERM纔會增長。Etcd的--snapshot-count=100，以便於觀察snap的生成規律，生產環境推薦10000。此時RAFT INDEX爲45，snap文件夾下還未生成snap文件
經過如下命令，向集羣提交100次寫入操做

for i in {1..100}
do
export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE put hello world$i
done

能夠看到，RAFT INDEX增長了100，與提交給集羣的寫入次數相同，而且集羣生成了一個快照文件00000000000004ac-0000000000000065.snap，其中00000000000004ac是RAFT TERM 1196的十六進制表示，0000000000000065是生成snap時，對應的RAFT INDEX的十六進制表示，0x65=101
執行如下命令兩次

for i in {1..110}
do
export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE put hello world$i
done

再向etcd寫入220次數據，又生成了兩個snap文件，其中文件名的後半部分0xca=202, 0x12f=303,因此當RAFT INDEX能整除--snapshot-count=100這個變量時，就會生成一個snap文件

備份操做

執行如下命令進行數據備份

export ETCDCTL_API=3;etcdctl --endpoints=$ENDPOINTS --cert $CERT_FILE --key $KEY_FILE --cacert $CA_FILE snapshot save cluster1_1198_366_49k.db

命令執行成功後，會生成數據文件cluster1_1198_366_49k.db，該文件可用於集羣恢復，其中1198是RAFT TERM,366是RAFT INDEX，用於記錄集羣當前的兩個狀態

從備份數據恢復集羣

執行下面的腳本，從備份的數據恢復集羣，執行成功後，會在各自--data-dir指定的目錄中生成數據目錄

restore-etcd-cluster.sh
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra4 
--data-dir=/var/lib/etcd/infra4 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23804
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra5 
--data-dir=/var/lib/etcd/infra5 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23805
etcdctl snapshot restore cluster1_1198_366_49k.db 
--name=infra6 
--data-dir=/var/lib/etcd/infra6 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806 
--initial-cluster-token=etcd-cluster-2 
--initial-advertise-peer-urls=https://$node4:23806

其中infra四、infra五、infra6是新生成的3個節點的數據目錄
分別執行如下3個腳本，來從恢復的數據目錄中啓動

start4.sh
#!/bin/bash
node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra4
etcd 
--name=infra4 
--initial-advertise-peer-urls=https://$node4:23804 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node4:23804 
--listen-client-urls=https://$node4:23794 
--advertise-client-urls=https://$node4:23794 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

start5.sh

#!/bin/bash

node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra5

etcd 
--name=infra5 
--initial-advertise-peer-urls=https://$node5:23805 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node5:23805 
--listen-client-urls=https://$node5:23795 
--advertise-client-urls=https://$node5:23795 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806
start6.sh

#!/bin/bash

node4=192.168.0.204
node5=192.168.0.204
node6=192.168.0.204
DATA_DIR=/var/lib/etcd/infra6
etcd 
--name=infra6 
--initial-advertise-peer-urls=https://$node6:23806 
--cert-file=/etc/kubernetes/pki/etcd/server.crt 
--key-file=/etc/kubernetes/pki/etcd/server.key 
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt 
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key 
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt 
--client-cert-auth=true 
--peer-client-cert-auth=true 
--data-dir=$DATA_DIR 
--snapshot-count=100 
--listen-peer-urls=https://$node6:23806 
--listen-client-urls=https://$node6:23796 
--advertise-client-urls=https://$node6:23796 
--initial-cluster-token=etcd-cluster-2 
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23806

恢復集羣啓動成功後，查看以前寫入hello對應的值爲world110，正是咱們以前備份前最後寫入的值，說明集羣恢復是正確的

更新節點advertise client URLs

測試目標：將測試集羣中node6的client urls端口由23796改成23797
更改start6.sh腳本中的對應行以下：

--listen-client-urls=https://$node6:23797 
--advertise-client-urls=https://$node6:23797

Kill掉node6節點的etcd，後再執行start6.sh啓動node6
從新啓動後，node6的client urls已經更新

更新節點的peer urls

測試目標：將測試集羣中node6的peer urls端口由23806改成23807

  • 更改start6.sh腳本中的對應行以下
--initial-advertise-peer-urls=https://$node6:23807    
--listen-peer-urls=https://$node6:23807   
--initial-cluster=infra4=https://$node4:23804,infra5=https://$node5:23805,infra6=https://$node6:23807
  • 經過member list指令獲取node id
  • 經過member update更新node的peer urls
  • Kill node6節點，再使用更新後的start6.sh腳本啓動node6節點

測試結果如上圖，node6的peer url更新成功

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程