pod 公升級方式：
1、刪掉舊pod,在部署新pod.
2、建立新pod,通過修改service選擇器後刪除舊pod
3、滾動式公升級 rolling-update
4、使用deployment宣告方式公升級
前兩者不在詳述，都需要中斷業務。
kubectl 滾動式公升級：
實驗：定義kubia-v1 yaml 檔案建立pod 和service
apiversion: v1
kind: replicationcontroller
metadata:
name: kubia-v1
spec:
replicas: 3
template:
metadata:
name: kubia
lebels:
spec:
containers:
- images: luksa/kubia:v1
name: nodejs
---apiversion: v1
kind: service
metadata:
name: kubia-v1
spec:
type: loadbalancer
selector:
ports:
- port: 80
targetport: 8080
kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2 #執行替換命令.乙個新的rc會被建立，初始副本為0。
kubectl describe rc kubia-v2 #檢視kubia-v2的rc
隨著kubectl繼續滾動公升級，開始看到越來越多的請求被切換到v2 pod,v1的pod 不斷的被刪除。
rolling-update的方式公升級需要執行 kubectl 命令，如果在公升級過程中失去網路連線公升級程序會將中斷。 rolling-update是一種淘汰的公升級方式。
deployment 宣告式公升級
deployment用於部署應用程式並已宣告的方式公升級應用、而不是通過rc,rs進行部署。
使用deployment時，實際上pod是由deployment的replicaset建立和管理的，不是由deployment直接建立和管理。
deployment也是由標籤選擇器、期望副本數和pod模本組成，此外還包含乙個字段指定乙個部署策略，該策略定義在修改deployment資源時應該如何執行更新。
建立乙個deployment yaml 檔案
kind: deployment #kind 名稱為deployment
metadata:
name: kubia #deployment名稱中不在需要版本號
spec:
replicas: 3
template:
metadata:
name: kubia
labels:
spec:
contaoners:
- image: luksa/kubia:v1
name: nodejs
kubectl create -f kubia-deployment.yaml --record #建立deployment， --record 引數會記錄歷史版本號。
可以同過kubectl get deployment 和 kubectl describe deployment 檢視詳細資訊。
kubectl rollout status deployment kubia #檢視 kubia的部署狀態。
deployment 公升級策略：
1、滾動式公升級（rollingupdate）
2、recreate （逐漸刪除舊pod,逐漸建立新pod)
要觸發公升級，只需要修改deployment的yaml 檔案即可。
kubectl set image deployment kubia nodejs=lunksa/kubia:v2 #這條命名會將模板裡的映象修改為lunksa/kubia:v2 （新版本）修改完成後會開始滾動公升級。
修改deployment或者其他資源的不同方式：
方法作用
kubectl edit
使用預設編輯器開啟資源配置，修改儲存並退出編輯器
例： kubectl edit deployment kubia
kubectl patch
修改單個資源屬性
例：kubectl patch deployment kubia -p 『]}}}
通過乙個完整的yaml或json 檔案，應用其中新的值來修改物件，如果yaml或json中指定的物件不存在，則會被建立。該檔案需要包含資源的完整定義，（不能像 kubectl patch 那樣只建立想要更新的字段）
kubectl replace
kubectl replace -f kubia-deployment-v2.yaml
kubectl setimage
修改pod、rs、rc、 deployment 、demonset 、job內的映象
例：kubectl set image deploymen kubia nodejs=luksa/kubia:v2
回滾公升級：
kubectl rollout undo deployment kubia #回滾到上乙個版本
kubectl rollout history deployment kubia # 檢視kubia 歷史版本
kubectl rollout undo deployment kubia —to-revision=1 #回滾到指定版本
暫停滾動公升級：
如果想讓新版和舊版pod混合執行、看看新版pod執行是否正常則在執行公升級幾秒後在執行暫停公升級命令。
kubectl rollout pause deployment kubia
恢復滾動公升級：
確認了剛才新版沒有問題，可以繼續公升級替換所以舊版本pod，可以執行恢復公升級命令。
kubectl rollout resume deployment kubia
取消出錯滾動公升級 :
kubectl describe deploy kubia # 檢視deployment的詳細情況。
如果出現progressdeadlineexceeded記錄，則表示完成滾動公升級時間太久。
可通過設定deployment spec 中使用 progressdeadlineseconds來指定時間。
因為錯誤滾動公升級不能在繼續，所以執行下面命令取消公升級。
kubectl rollout undo deployment kubia
openssh公升級和回滾
公升級有很多教程，但是回滾沒有很詳細的教程，因為回滾操作很少操作，但是生產環境要有預案，雖然我的回滾解決辦法有點蠢，但是沒有時間去研究那摩多，當時，直接把有關原環境資訊cp備份，然後回滾的時候還原。親測可用！wget o openssh 8.4p1.tar.gz wget o zlib 1.2.11...
事務回滾與手動回滾
一般我們在開發時，在方法或者類上加了 transactional事務註解，然後會用 try catch 將可能會出問題的 塊包起來，在catch裡面處理捕獲的異常，但是，如果在catch裡面沒有把異常丟擲去，此時事務是不會自動回滾的 比如這種情況 這裡既沒有丟擲異常，也沒有手動回滾，在插入流水表之後...
NameNode節點的公升級 回滾 提交
我記得在前面已經以regular方式為例詳細的講述了有關namenode啟動的過程，在開始本文的重點之前，我覺得還是有必要在簡單的描述一下這個過程 好了，再回到本文將要闡述的重點吧 namenode節點的公升級 回滾 提交，這一步實際上只發生在上面過程的第一步 載入fsimage editlog。前...