kubernetes, sdn, linux,devops

本篇文章會開始探討 kubernetes Container Runtime Interface 的概念與設計，並且討論其餘 OCI 的關係，最後介紹了 Docker/Containerd 這些不的 Container 解決方案是如何於 Kubernetes 共存的

本篇文章作為 Container 介紹的最後一篇，簡單的透過 namespace 的操作讓大家看看 network 以及 storage 本身的運行模式，接下來到 CNI 以及 CSI 相關的章節的時候會再仔細介紹 kubernetes 中是怎麼處理 network 與 storage 這兩大重要資源。

本文延續前篇文章關於 Open Container Initiatives 的討論，前篇文章討論了關於 OCI 內的兩大標準，分別是 Runtime 以及 Image 這兩項關於 Container 的標準，而本篇文章則是會介紹如了相關的標準之外，目前有什麼相關的解決方案與工具與這兩個標準息息相關，同時對於 Docker 本身會怎麼利用這些標準來完成 COntainer 的運行

本文針對 Container 的概念進行探討，特別是其相關標準 Open Container Initiative (OCI), OCI 中定義了兩項規格，分別是 Runtime specification 以及 Image specification. 本文粗略地介紹一下彼此的概念以及各自負責的功能

為了跟大家分享 kubernetes 內部的幾個重要設計，如 CRI, CSI 以及 CNI, 本篇文章先簡單介紹了一下 kubernetes 內部相關的設計理念，透過理解這些理念更可以理解為什麼會有各式各樣的介面被設計出來。

用此文記錄一下新生活的生活進度，特別是一開始前往生活時有多少的文件要申請

本文分享如何透過一些常見的方法或是別人撰寫好的工具來提供一個方便的管理工具，讓操作者可以更方便的再多個 AWS 帳號中進行切換

隨者愈來愈多的 CI/CD 工具被開發出來，對於維運/開發者來說，到底要選擇哪一套 CI/CD 工具來使用? 本文介紹了其中一款 SaaS 服務, CircleCI。 本文簡單介紹一下作者自己在選擇工具時會考慮的問題與情境，以及在什麼情境下選擇了使用 CircleCI, 最後介紹了幾個覺得好用的功能。

除了自行架設 Kubernetes 之外，採用公有雲廠商所提供的 Kubernetes Service 也是一個方便的選擇，然而這種情況下有許多的設定跟功能都會依賴該公有雲廠商自行實作，大部分的功能都會與公有雲本身的架構進行高度整合以提供更方便的使用與操作。本文針對 Container Network Interface (CNI) 於 Azure 中的實現與使用進行了討論，藉此了解公有雲的 CNI 有什麼特別的設計與使用方式

Kubernetes 的蓬勃發展以及其人氣帶來廣泛地使用，然而就現實中，其實出現了不少關於 kubernetes 不太正確的想像與理解，愈來愈多的人因應 kubernetes 的發展就將 kubernetes 視為一個完美的解藥，能夠解決所有營運部署的所有困難與需求。最後發現現實與理想沒有辦法妥協時就會露出失望與無奈的表情。其實問題就出在一開始沒有理解到底 kubernetes 能夠帶來什麼樣的優勢以及本身有什麼樣的能力與限制。本文針對一些常見的三大資源，儲存/網路/運算 介紹了一下筆者自己觀察以及理解的概念去描述到底 kubernetes 能夠做什麼，不能夠做什麼