2 files changed, 3 insertions(+), 3 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/3.RelatedWorks.tex

@@ 19,7 19,7 @@ Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對
     \item 使用者透過更新後的 status 欄位得知操作結果
 \end{enumerate}
 
-\begin{figure}
+\begin{figure}[htb]
     \centering
     \includegraphics{assets/kubernetes.png}
     \caption{Kubernetes 操作模型簡易示意圖}


@@ 63,7 63,7 @@ Helm 是用來簡化 Kubernetes 上的應用部屬流程的工具，其手段是
 
 Helm 用來產生 Kubernetes resources 的模板稱為 Helm Chart，Helm Charts 會集中在 Helm Repository 裡提供使用，Helm Chart 的模板參數稱為 Helm Values，由 Helm 安裝起來的一套應用稱為 Helm Release。透過模板產生的 resources 定義除了套用到 Kubernetes 上之外，Release 會對 resources 額外進行版本紀錄，用以實做更新、回滾、解除安裝等操作。Release 的版本追蹤資訊通常以 Secrets\footnote{Secret: Kubernetes resources 種類，提供資料儲存，本身並不帶有任何功能。} 的形式儲存在叢集內。
 
-\begin{figure}
+\begin{figure}[htb]
     \centering
     \includegraphics{assets/helm.png}
     \caption{Helm 原理示意圖}

@@ 13,7 13,7 @@
 
 在實做方面，為了簡化同時避免使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resources 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通。另外安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面只提供極少數的 Charts 開放使用，並由程式邏輯產生其 Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由類似的方式可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。在部屬單一網頁服務的部份，則是採用內建的 resources 模板再針對特定欄位提供表單客製化，因此成果也容易顯的相當侷限，以這個角度設計容易帶有過多的假設，例如假定只須一個容器、假定容器提供服務的 HTTP port 等，並且沒有顧慮到如安裝資料庫等網頁服務本體外的基礎建設場景。
 
-\begin{figure}
+\begin{figure}[htb]
     \centering
     \includegraphics{assets/CScloudV2.png}
     \caption{CScloud with PEKOS 實做架構簡易示意圖}