dashboard中文的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列包括價格和評價等資訊懶人包

Google聯手IBM：Istio架構一統微服務世界

為了解決dashboard中文的問題，作者崔秀龍 這樣論述：

　　在微服務浪潮的推動之下，微服務的治理成為新的技術熱點，從Linkerd提出Service Mesh（服務網格）概念開始，這一理念的幾個相關產品經過一番短暫較量，Google/IBM/Lyft合作推出的 Istio 系統成為目前服務網格技術的事實標準。 　　本書圍繞Istio 對服務網格的概念、歷史和能力，以各種實例為基礎，試圖從基本概念開始，結合實際工作場景和企業試點採納步驟，進行易於上手和了解的說明，提供給讀者對這一新生系統一個相對完整的應用指南。 　　透過作者對Istio 的深入了解和實戰經驗，可以幫助讀者快速入門和實作。 　　本書主要內容： 　　■ 服務網格

的歷史 　　■ 服務網格的基本特性    　　■ Istio 基本介紹 　　■ Istio 快速入門    　　■ 用Helm 部署Istio   　　■ Istio 的常用功能 　　■ HTTP 流量管理 　　■ Mixer 介面卡的應用 　　■ Istio 的安全強化 　　■ Istio 的試用建議    本書特色 　　◎圍繞Istio核心特性，精選應用場景 　　◎快速入門Istio、了解Service Mesh  

dashboard中文進入發燒排行的影片

疫苗分配之公平正義初探：以新冠肺炎疫苗為例

為了解決dashboard中文的問題，作者邱雯萍 這樣論述：

新冠肺炎疫苗分配所存在的不公平正義，歸咎主因為疫苗供應不足，研究動機係依據KEYPO大數據關鍵引擎及關鍵評論網統計調查網路聲量，討論度及對於疫情不滿，都集中在3+11及缺疫苗(供貨量與疫苗種類選擇不足)等2個議題上，研究工具採用內容分析法進行，並以公平理論Leventhal所提出之6個評判程序的標準，進行3+11事件、第2類施打對象順序爭議、採購疫苗政策失策、民間團體採購捐贈疫苗、10大類疫苗接種對象、疑涉施打對象不符及疫苗預約平台等7個輿情事件，執行疫苗分配程序之公平標準，研究結果如下，以橫向分析發現3+11事件與疑涉施打對象不符事件缺乏一致性、不偏私及資訊正確等公平標準，第2類施打對象爭

議未符合一致性、不偏私及倫理等公平標準，採購疫苗政策失策及民間團體採購疫苗同樣未有一致性、不偏私及代表性等公平標準，10類疫苗接種對象爭議未符合一致性及代表性等公平標準，疫苗預約平台未有一致性及矯正等公平標準。另以3+11、第2類施打對象順序爭議、採購疫苗政策失策、民間團體疫苗採購及疑涉施打對象不符等5個事件皆超過3項不符合公平標準，輿論爭議顯較大，另10類疫苗接種對象及疫苗預約平台等3個事件超過2項不符合公平標準，在爭議上比前5個事件上顯較不顯著。縱向分析結果發現7個事件皆違反一致性公平標準，不偏私次之，代表性佔第三。

Kubernetes in Action中文版

為了解決dashboard中文的問題，作者（美）馬爾科·盧克沙 這樣論述：

本書主要講解如何在Kubernetes中部署分散式容器應用。本書開始部分概要介紹了Docker和Kubernetes的由來和發展，然後通過在Kubernetes中部署一個應用程序，一點點增加功能，逐步加深我們對於Kubernetes架構的理解和操作的實踐。在本書的後面部分，也可以學習一些高階的主題，比如監控、調試及伸縮。Kubernetes是希臘文，意思是「舵手」，帶領我們安全地到達未知水域。Kubernetes這樣的容器編排系統，會幫助我們妥善地管理分散式應用的部署結構和線上流量，高效地組織容器和服務。Kubernetes作為數據中心操作系統，在設計軟體系統時，能夠盡量降低在底層網路和硬體設

施上的負擔。 [美]馬爾科·盧克沙(Marko Luksa)，是一位擁有20年以上專業開發經驗的軟體工程師，經手項目小到簡單的Web應用，大到ERP系統、框架和中間件軟體，應有盡有。在為Red Hat工作期間，他從Google App Engine API實現的開發起步, 這些API將基於Red Hat的JBoss中間件產品，之後他一直在為CDI/Weld、Infinispan/JBoss DataGrid等項目貢獻力量。2014后, 他加入Red Hat的Cloud Enablement團隊，負責 Kubernetes和相關技術開發的更新，保障公司的中間件軟體能將Ku

bernetes與OpenShift特性的潛能完全發揮出來。 七牛容器雲，（KIRK）團隊，是負責七牛雲基於自身公有雲業務在容器方面的多年實踐經驗，針對企業應用快速部署、便捷運維打造的容器雲計算平台。提供持續集成、彈性伸縮、應用市場等功能特性，使企業專註于業務邏輯開發，縮短業務上線周期，優化資源利用率，提高服務響應效率的一支技術團隊。 1 　Kubernetes 介紹1 1.1　Kubernetes 系統的需求 2 1.1.1　從單體應用到微服務 2 1.1.2　為應用程式提供一個一致的環境 5 1.1.3　邁向持續交付 ：DevOps 和無運維 6 1.2　介紹容器技術

7 1.2.1　什麼是容器 7 1.2.2　Docker 容器平臺介紹 11 1.2.3　rkt——一個 Docker 的替代方案 14 1.3　Kubernetes 介紹 15 1.3.1　初衷 15 1.3.2　深入淺出地瞭解 Kubernetes 15 1.3.3　Kubernetes 集群架構 17 1.3.4　在 Kubernetes 中運行應用 18 1.3.5　使用 Kubernetes 的好處 20 1.4　本章小結 22 2 　開始使用 Kubernetes 和 Docker 23 2.1　創建、運行及共用容器鏡像 23 2.1.1　安裝 Docker 並運行 Hello W

orld 容器 24 2.1.2　創建一個簡單的 Node.js 應用 26 2.1.3　為鏡像創建 Dockerfile 27 2.1.4　構建容器鏡像 27 2.1.5　運行容器鏡像 30 2.1.6　探索運行容器的內部 31 2.1.7　停止和刪除容器 32 2.1.8　向鏡像倉庫推送鏡像 33 2.2　配置 Kubernetes 集群 34 2.2.1　用 Minikube 運行一個本地單節點 Kubernetes 集群 34 2.2.2　使用 Google Kubernetes Engine 託管 Kubernetes 集群 36 2.2.3　為 kubectl 配置別名和命令列補齊

39 2.3　在 Kubernetes 上運行第一個應用 40 2.3.1　部署 Node.js 應用 40 2.3.2　訪問 Web 應用 43 2.3.3　系統的邏輯部分 45 2.3.4　水準伸縮應用 46 2.3.5　查看應用運行在哪個節點上 49 2.3.6　介紹 Kubernetes dashboard 50 2.4　本章小結 51 3 　pod ：運行於 Kubernetes 中的容器 53 3.1　介紹 pod 53 3.1.1　為何需要 pod 54 3.1.2　瞭解 pod 55 3.1.3　通過 pod 合理管理容器 56 3.2　以 YAML 或 JSON 描述檔創建

pod 58 3.2.1　檢查現有 pod 的 YAML 描述檔 59 3.2.2　為 pod 創建一個簡單的 YAML 描述檔 61 3.2.3　使用 kubectl create 來創建 pod 63 3.2.4　查看應用程式日誌 64 3.2.5　向 pod 發送請求 65 3.3　使用標籤組織 pod 66 3.3.1　介紹標籤 66 3.3.2　創建 pod 時指定標籤 67 3.3.3　修改現有 pod 的標籤 68 3.4　通過標籤選擇器列出 pod 子集 69 3.4.1　使用標籤選擇器列出 pod 69 3.4.2　在標籤選擇器中使用多個條件 71 3.5　使用標籤和選擇器

來約束 pod 調度 71 3.5.1　使用標籤分類工作節點 72 3.5.2　將 pod 調度到特定節點 72 3.5.3　調度到一個特定節點 73 3.6　注解 pod73 3.6.1　查找對象的注解 74 3.6.2　添加和修改注解 74 3.7　使用命名空間對資源進行分組 75 3.7.1　瞭解對命名空間的需求 75 3.7.2　發現其他命名空間及其 pod 75 3.7.3　創建一個命名空間 76 3.7.4　管理其他命名空間中的物件 77 3.7.5　命名空間提供的隔離 78 3.8　停止和移除 pod 78 3.8.1　按名稱刪除 pod 78 3.8.2　使用標籤選擇器刪除 p

od 79 3.8.3　通過刪除整個命名空間來刪除 pod 80 3.8.4　刪除命名空間中的所有 pod，但保留命名空間 80 3.8.5　刪除命名空間中的（幾乎）所有資源 80 3.9　本章小結 81 4 　副本機制和其他控制器 ：部署託管的 pod 83 4.1　保持 pod 健康 84 4.1.1　介紹存活探針 84 4.1.2　創建基於 HTTP 的存活探針 85 4.1.3　使用存活探針 86 4.1.4　配置存活探針的附加屬性 87 4.1.5　創建有效的存活探針 88 4.2　瞭解 ReplicationController 89 4.2.1　ReplicationContro

ller 的操作 90 4.2.2　創建一個 ReplicationController 92 4.2.3　使用 ReplicationController 94 4.2.4　將 pod 移入或移出 ReplicationController 的作用域 97 4.2.5　修改 pod 範本 100 4.2.6　水準縮放 pod 101 4.2.7　刪除一個 ReplicationController 103 4.3　使用 ReplicaSet 而不是 ReplicationController 104 4.3.1　比較 ReplicaSet 和 ReplicationController 10

4 4.3.2　定義 ReplicaSet 105 4.3.3　創建和檢查 ReplicaSet106 4.3.4　使用 ReplicaSet 的更富表達力的標籤選擇器106 4.3.5　ReplicaSet 小結 107 4.4　使用 DaemonSet 在每個節點上運行一個 pod 107 4.4.1　使用 DaemonSet 在每個節點上運行一個 pod 108 4.4.2　使用 DaemonSet 只在特定的節點上運行 pod 109 4.5　運行執行單個任務的 pod 112 4.5.1　介紹 Job 資源 112 4.5.2　定義 Job 資源 113 4.5.3　看 Job 運行

一個 pod 114 4.5.4　在 Job 中運行多個 pod 實例 114 4.5.5　限制 Job pod 完成任務的時間 116 4.6　安排 Job 定期運行或在將來運行一次 116 4.6.1　創建一個 CronJob 116 4.6.2　瞭解計畫任務的運行方式 118 4.7　本章小結 118 5 　服務 ：讓用戶端發現 pod 並與之通信121 5.1　介紹服務 122 5.1.1　創建服務 123 5.1.2　服務發現 129 5.2　連接集群外部的服務 132 5.2.1　介紹服務 endpoint 133 5.2.2　手動配置服務的 endpoint 133 5.2.3　

為外部服務創建別名 135 5.3　將服務暴露給外部用戶端 136 5.3.1　使用 NodePort 類型的服務 137 5.3.2　通過負載等化器將服務暴露出來 140 5.3.3　瞭解外部連接的特性 142 5.4　通過 Ingress 暴露服務 143 5.4.1　創建 Ingress 資源 145 5.4.2　通過 Ingress 訪問服務 146 5.4.3　通過相同的 Ingress 暴露多個服務 147 5.4.4　配置 Ingress 處理 TLS 傳輸 149 5.5　pod 就緒後發出信號 150 5.5.1　介紹就緒探針 151 5.5.2　向 pod 添加就緒探針 1

52 5.5.3　瞭解就緒探針的實際作用 154 5.6　使用 headless 服務來發現獨立的 pod 155 5.6.1　創建 headless 服務156 5.6.2　通過 DNS 發現 pod 156 5.6.3　發現所有的 pod——包括未就緒的 pod 157 5.7　排除服務故障 158 5.8　本章小結 159 6 　卷 ：將磁片掛載到容器 161 6.1　介紹卷 162 6.1.1　卷的應用示例162 6.1.2　介紹可用的卷類型 164 6.2　通過卷在容器之間共用資料 165 6.2.1　使用 emptyDir 卷 165 6.2.2　使用 Git 倉庫作為存儲卷 16

8 6.3　訪問工作節點檔案系統上的文件 171 6.3.1　介紹 hostPath 卷 171 6.3.2　檢查使用 hostPath 卷的系統 pod 172 6.4　使用持久化存儲 173 6.4.1　使用 GCE 持久磁片作為 pod 存儲卷 174 6.4.2　通過底層持久化存儲使用其他類型的卷 177 6.5　從底層存儲技術解耦 pod 179 6.5.1　介紹持久卷和持久卷聲明 179 6.5.2　創建持久卷 180 6.5.3　通過創建持久卷聲明來獲取持久卷 182 6.5.4　在 pod 中使用持久卷聲明 184 6.5.5　瞭解使用持久卷和持久卷聲明的好處 185 6.5.

6　回收持久卷 186 6.6　持久卷的動態磁碟區配置 187 6.6.1　通過 StorageClass 資源定義可用存儲類型 188 6.6.2　請求持久卷聲明中的存儲類 188 6.6.3　不指定存儲類的動態配置 190 6.7　本章小結 193 7 　ConfigMap 和 Secret ：配置應用程式 195 7.1　配置容器化應用程式 195 7.2　向容器傳遞命令列參數 196 7.2.1　在 Docker 中定義命令與參數 196 7.2.2　在 Kubernetes 中覆蓋命令和參數 199 7.3　為容器設置環境變數 200 7.3.1　在容器定義中指定環境變數 201 7

.3.2　在環境變數值中引用其他環境變數 201 7.3.3　瞭解硬編碼環境變數的不足之處 202 7.4　利用 ConfigMap 解耦配置 202 7.4.1　ConfigMap 介紹 202 7.4.2　創建 ConfigMap 203 7.4.3　給容器傳遞 ConfigMap 條目作為環境變數 206 7.4.4　一次性傳遞 ConfigMap 的所有條目作為環境變數 208 7.4.5　傳遞 ConfigMap 條目作為命令列參數 209 7.4.6　使用 configMap 卷將條目暴露為檔 210 7.4.7　更新應用配置且不重啟應用程式 216 7.5　使用 Secret 給

容器傳遞敏感性資料 218 7.5.1　介紹 Secret 218 7.5.2　默認權杖 Secret 介紹 218 7.5.3　創建 Secret 220 7.5.4　對比 ConfigMap 與 Secret 221 7.5.5　在 pod 中使用 Secret 222 7.6　本章小結 228 8 　從應用訪問 pod 中繼資料以及其他資源 229 8.1　通過 Downward API 傳遞中繼資料 229 8.1.1　瞭解可用的中繼資料 230 8.1.2　通過環境變數暴露中繼資料 231 8.1.3　通過 downwardAPI 卷來傳遞中繼資料 234 8.2　與 Kuberne

tes API 伺服器交互 237 8.2.1　探究 Kubernetes REST API 238 8.2.2　從 pod 內部與 API 伺服器進行交互 242 8.2.3　通過 ambassador 容器簡化與 API 伺服器的交互 248 8.2.4　使用用戶端庫與 API 伺服器交互 251 8.3　本章小結 253 9 　Deployment: 聲明式地升級應用 255 9.1　更新運行在 pod 內的應用程式 256 9.1.1　刪除舊版本 pod，使用新版本 pod 替換257 9.1.2　先創建新 pod 再刪除舊版本 pod 257 9.2　使用 ReplicationCo

ntroller 實現自動的輪流升級259 9.2.1　運行第一個版本的應用 259 9.2.2　使用 kubectl 來執行滾動式升級 261 9.2.3　為什麼 kubectl rolling-update已經過時 265 9.3　使用 Deployment 聲明式地升級應用 266 9.3.1　創建一個 Deployment 267 9.3.2　升級 Deployment 269 9.3.3　回滾 Deployment 273 9.3.4　控制輪流升級速率 276 9.3.5　暫停輪流升級 278 9.3.6　阻止出錯版本的輪流升級 279 9.4　本章小結 284 10 　Statef

ulSet ：部署有狀態的多副本應用 285 10.1　複製有狀態 pod 285 10.1.1　運行每個實例都有單獨存儲的多副本 286 10.1.2　每個 pod 都提供穩定的標識 287 10.2　瞭解 Statefulset 289 10.2.1　對比 Statefulset 和 ReplicaSet 289 10.2.2　提供穩定的網路標識 290 10.2.3　為每個有狀態實例提供穩定的專屬存儲 292 10.2.4　Statefulset 的保障 294 10.3　使用 Statefulset 295 10.3.1　創建應用和容器鏡像 295 10.3.2　通過 Stateful

set 部署應用 296 10.3.3　使用你的 pod 301 10.4　在 Statefulset 中發現夥伴節點 305 10.4.1　通過 DNS 實現夥伴間彼此發現 306 10.4.2　更新 Statefulset 308 10.4.3　嘗試集群資料存儲 309 10.5　瞭解 Statefulset 如何處理節點失效 310 10.5.1　類比一個節點的網路斷開 310 10.5.2　手動刪除 pod 312 10.6　本章小結 313 11 　瞭解 Kubernetes 機理 315 11.1　瞭解架構 315 11.1.1　Kubernetes 組件的分散式特性 316 11

.1.2　Kubernetes 如何使用 etcd 318 11.1.3　API 伺服器做了什麼 322 11.1.4　API 伺服器如何通知用戶端資源變更 324 11.1.5　瞭解調度器 325 11.1.6　介紹控制器管理器中運行的控制器 327 11.1.7　Kubelet 做了什麼 331 11.1.8　Kubernetes Service Proxy 的作用 332 11.1.9　介紹 Kubernetes 外掛程式 333 11.1.10　總結概覽 335 11.2　控制器如何協作 335 11.2.1　瞭解涉及哪些組件335 11.2.2　事件鏈 336 11.2.3　觀察集群

事件 337 11.3　瞭解運行中的 pod 是什麼 339 11.4　跨 pod 網路 340 11.4.1　網路應該是什麼樣的 340 11.4.2　深入瞭解網路工作原理 341 11.4.3　引入容器網路介面 343 11.5　服務是如何實現的 344 11.5.1　引入 kube-proxy 344 11.5.2　kube-proxy 如何使用 iptables 344 11.6　運行高可用集群 346 11.6.1　讓你的應用變得高可用 346 11.6.2　讓 Kubernetes 控制平面變得高可用 347 11.7　本章小結 350 12 　Kubernetes API 伺服器

的安全防護 351 12.1　瞭解認證機制 351 12.1.1　用戶和組 352 12.1.2　ServiceAccount 介紹 353 12.1.3　創建 ServiceAccount 354 12.1.4　將 ServiceAccount 分配給 pod 356 12.2　通過基於角色的許可權控制加強集群安全 358 12.2.1　介紹 RBAC 授權外掛程式 359 12.2.2　介紹 RBAC 資源 360 12.2.3　使用 Role 和 RoleBinding 363 12.2.4　使用 ClusterRole 和 ClusterRoleBinding 367 12.2.5　瞭

解默認的 ClusterRole 和 ClusterRoleBinding 376 12.2.6　理性地授予授權許可權 379 12.3　本章小結 379 13 　保障集群內節點和網路安全 381 13.1　在 pod 中使用宿主節點的 Linux 命名空間 381 13.1.1　在 pod 中使用宿主節點的網路命名空間382 13.1.2　綁定宿主節點上的埠而不使用宿主節點的網路命名空間 383 13.1.3　使用宿主節點的 PID 與 IPC 命名空間 385 13.2　配置節點的安全上下文 386 13.3　限制 pod 使用安全相關的特性 396 13.4　隔離 pod 的網路 406

13.5　本章小結 410 14 　計算資源管理 411 14.1　為 pod 中的容器申請資源 411 14.1.1　創建包含資源 requests 的 pod 412 14.1.2　資源 requests 如何影響調度 413 14.1.3　CPU requests 如何影響 CPU 時間分配 418 14.1.4　定義和申請自訂資源 418 14.2　限制容器的可用資源 419 14.3　瞭解 pod QoS 等級 423 14.4　為命名空間中的 pod 設置默認的 requests 和 limits 427 14.5　限制命名空間中的可用資源總量 431 14.6　監控 pod 的

資源使用量 436 14.7　本章小結 442 15 　自動橫向伸縮 pod 與集群節點 443 15.1　pod 的橫向自動伸縮 444 15.2　pod 的縱向自動伸縮 456 15.3　集群節點的橫向伸縮 457 15.4　本章小結 461 16 　高級調度463 16.1　使用污點和容忍度阻止節點調度到特定節點 463 16.2　使用節點親緣性將 pod 調度到特定節點上 469 16.3　使用 pod 親緣性與非親緣性對 pod 進行協同部署 475 16.4　本章小結 483 17 　開發應用的最佳實踐 485 17.1　集中一切資源 486 17.2　瞭解 pod 的生命週期 4

87 17.3　確保所有的用戶端請求都得到了妥善處理 500 17.4　讓應用在 Kubernetes 中方便運行和管理 505 17.5　開發和測試的最佳實踐 510 17.6　本章小結 515 18 　Kubernetes 應用擴展 517 18.1　定義自訂 API 物件 517 18.2　使用 Kubernetes 服務目錄擴展 Kubernetes 528 18.3　基於 Kubernetes 搭建的平臺 536 18.4　本章小結 541 A 　在多個集群中使用 kubectl 543 B 　使用 kubeadm 配置多節點集群 549 C 　使用其他容器運行時 563 D 　Cl

uster Federation 567  

營建工程資訊儀表板管理系統設計與分析

為了解決dashboard中文的問題，作者葉哲仰 這樣論述：

以現今國內的營造業來看，在管理工程專案時仍以書面為重，僅有部份資料與日誌內容運用此方式進行整合，也因此在資料間的聯結性則有較弱之情形產生，造成管理層面產生繁複資訊以及效率低化，皆會影響整體施工專案的執行情況。因此本研究系統期以資訊化管理畫面達到將資訊量減化的統整性，並將施工日誌之記錄資訊一併與資訊化系統整合，清楚呈現和提供相關重點資料之通知管理，在通知管理狀況下能有效的在管理端與施工端做資訊傳遞，給予準確性高且完整的決策方案讓施工專案能有更好的執行率也簡化業主人員所可能面臨的資訊繁複的困境。本研究系統以如戰情室管理般的資訊畫面，首先以現況與需求進行分析，來了解在工程專案上所著重之管理重點為何

；其次為在研究系統的架構與介面功能之設計，分析出重點資料來進行系統資料庫的建置，並將所需資料模型化後讓資料彼此能有效的做聯結，建立於資料庫中提供系統之發展與使用；最後則將上述之資料做完整性的合併與統整，設計出所要提供與呈現的資訊化管理畫面，讓業主人員能有互動化、視覺化、統整化的操作模式。本研究管理系統做為設計管理之基礎，並發展出視覺化的管理模式，研究結果可作為日後工程資訊介面發展的參考依據。