溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
后期展望包括下面幾個部分：
啟動項管理，這個對應在啟動上有先后順序依賴的應用來說，是一個強訴求。目前docker compose 支持通過depends_on標簽實現多個組件間啟動順序的管理。
k8s目前還不支持指定啟動順序的，只能通過init_container，在實例容器啟動前對依賴的服務進行檢測，檢測到依賴的服務啟動后再啟動相應的容器。
2、應用下的日志聚合，其實這里應該還包括監控數據聚合。這個需求應該是系統基于服務組管理后的一個延展訴求，可以進一步強化服務組管理的能力。
3、調用關系展示，這個需求進一步在應用中突出服務與服務之間的依賴關系。更進一步對于調用鏈的追蹤也是一個強訴求。
公共模板與應用市場，這個是應用編排更高階的一個形式。通過應用市場可以快速的實現通用軟件的容器化部署。
接下來是互動問答的內容：
Q: 應用下的服務展示（未部署），是yaml資源沒有創建，還是副本數為0？
W: 未部署狀態是yaml資源還沒有創建
Q: 騰訊云能否將Kubernetes應用編排過程做成博客或視頻的形式具體分享一下？
W: 我們接下來會將Kubernetes應用編排過程做成博客分享出來，后面也會做出視頻分享給大家
Q: 騰訊云k8s網絡用的是哪個組件呢？
W: 我們用的是全局路由的方式，直接和我們騰訊云容器服務的VPC網絡打通。
Q: 使用configmap的時候，在配置修改完，需要重啟服務。騰訊云容器服務配置文件的變更如何觸發服務的重新啟動？
W: 通過觸發器的模式，可以在修改配置時觸發服務的更新。
Q: 之前講到可以結合CI/CD流程，通過CI編譯生成新的鏡像，修改配置項中鏡像tag的參數，自動觸發對應服務的更新。 這部分有詳細例子嗎？
W: 我們會將詳細示例放到騰訊云容器服務幫助文檔，在騰訊云分享論壇--騰云閣后面也可以看到。
Q: 應用配置如何實現版本控制的？
W: 對于每一個配置文件，我們支持每一次修改默認創建一個新的版本，具有唯一的版本號
Q：應用里的服務具體要怎么更新呢？
W: 一般建議的更新方法是，先修改配置，會生成配置的一個新的版本，這樣這次修改在配置中是可以記錄的。然后更新應用匯總配置文件的版本。觸發或者手動更新對應的服務。
在修改配置文件的版本后，我們會比較出哪些服務有變化，需要更新。
Q：應用里的服務具體要怎么更新呢？
W: 一般建議的更新方法是，先修改配置，會生成配置的一個新的版本，這樣這次修改在配置中是可以記錄的。然后更新應用匯總配置文件的版本。觸發或者手動更新對應的服務。
在修改配置文件的版本后，我們會比較出哪些服務有變化，需要更新。
Q: 外部訪問集群是通過Nginx轉發到pod還是通過k8s本來都dns服務來轉發，兩者優缺點是什么？
W: 外部訪問，支持兩種方式。
一種是通過服務的LB直接轉發到對應的Pod，但需要在創建服務時指定訪問方式為外部訪問(對應于k8s中的LoadBanace方式)。
另外一種是通過ingress的方式。這種方式會有一個統一的LB作為入口。然后配置對應的后端域名轉發規則。可以將外部的訪問按照配置的規則轉發后端的服務。
Q: 上面提到 應用模版+應用配置=應用實例，這樣一個應用模版可以對應多個應用配置并生成多份應用實例嗎？例如生成200個實例，如果可以如何寫ci比較合適？
W: 這個是可以的，并且我們提供集群隔離和命名空間隔離。方便多個應用實例的創建。
Q: 應用的擴容縮容通過什么監控，有什么指標可以參考？
W: 自動擴容和縮容我們參考的是社區HPA的方案。指標目前考慮的是CPU和內存。
Q: 狀態化的容器怎么做的？
W: 目前看到的有三種方式：一種是社區推薦的Stateful資源+headles service另外一種是：將服務的每一個實例拆分成獨立的headless service
第三種是： 采用CoreOS提出的operater方式。存儲部分一般推薦使用PVC的方式，但有其他的存儲方式也可以。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
