16 docs tagged with "Container"

The most import feature of the container is the resource isolation, including the mount, network, user, UTC and PID. that's the reason why we can't see those resources status of the host. The resources isolation are supported by the Linux Kernel and we will demostrate the networking part by the network namespace and also show you how does the docekr use the network namespace and Linux Bridge to proivde the network connectivity for each container.

Container Network Interface (CNI) as a Network Interface between the network soluition and the container mechanism. Without the CNI, the network solution developer should implement his/her plugin for every container environment and it must be a disaster. Fortunately, with the help of the CNI, the developer can only focus on one interface and it should work for every container mechanism. In this post, we will see why we need the CNI, what is CNI and how kubernetes use the CNI to provide the network connectiviy for the computing unit, so called Pod.

As we know, the kubernetes use the CNI to provide the network connectivity for its Pod unit and the cluster administrator can choose what kind of the CNI should be installed in the cluster. For example, if the only requirement is the overlay network, you can choose the flannel CNI and choose the calico CNI if you have the requirement of the BGP. In this post, we will learn how to write your own CNI in golang language. Actually, You can implement it with any language as you like.

本文主要跟大家分享如何透過 Static Pod 的方式來滿足用 Kubernetes 管理 API-Server/Controller/Scheduler 這些 Kubernetes 的基礎元件，其中 Static Pod 更是 Kubeadm 的架設原理，透過這個方式我們也可以更加了解 Kubeadm 的安裝方式

本文作為網路系列文章的第一篇，將從 Container Network Interface 下手，相對於 Container Runtime Interface, CNI 以是個類似的架構，但是主打網路能力為主，至於網路能力這個字眼其實很模糊，畢竟不同情境，不同需求都會有不同的實現方式，很難用一個通用的說法來函索有可能力。本文會跟大家介紹 CNI 的相關資訊，包括標準的內容，相關設定，最後也會透過一些比較跟大家介紹不同 Container 實現方式其最後底層去操作 CNI 的方式也截然不同

本文要特別介紹基於 Kubernetes 所開發的 CRI 解決方案 CRI-O, CRI-O 所有的功能都是為了 kubernetes 而設計，不多不少剛剛好，完全最佳化於 kubernetes。此外由於不需要倚賴太多第三方的元件，譬如 docker, containerd 等，使用 CRI-O 可以減少元件之間 IPC 溝通的次數進而提升整體的效率。 本文主要會介紹 CRI-O 的概念並且透過實際安裝的方式介紹如何幫 kubernetes 抽換 runtime 成 CRI-O

有鑒於 CRI 的標準架構，各式各樣的針對不同目標的專案都能夠整合到 Kubernetes 中，而本文要介紹的兩個專案分別是 gVisor 以及 kata-container, 這兩個專案都是基於安全性考量而開發的 OCI Runtine，與其相同地位的就是最知名的 OCI Runtime, runc。 本文會介紹這兩個專案的概念以及目標，並且討論其實作架構來比較這兩種不同的方式是如何達到安全的效果

本 blog 目前是採用 hexo 作為主要開發，然而 hexo 我覺得最大的缺點就是屬於靜態網頁類型，所以只要每次換一個開發裝置，譬如桌電,筆電等，就必須要將整個環境重新建置。

這篇延續上一篇Docker image for Hexo (一)，要使用上次的概念來打造一個屬於我自己的 hexo docker image，至於這邊為什麼是說屬於我自己的？

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

本文介紹了 `containerd 的概念，並且嘗試建置一個基於 containerd 的 kubernetes cluster, 讓大家體驗看看佈樁 docker 也可以運行 kubernetes 的使用方式，同時也可以學習到是如何透過設定來改變 kubernetes 這一連串的行為的。

Seucirty 一直以來都無法忽視的問題，平常不理他可能相安無事，一旦出事情必定人仰馬翻。然而對於 kubernetes 這樣的容器管理平台來說，安全這個概念涵蓋的範圍很大，從底層架構的部署，到 kubernetes 平台的搭建，容器本身的創建以及應用程式的撰寫，每個環節都有安全的問題需要考量。本章節會針對容器相關的一些權限部分進行探討，並且從 kubernetes pod 的格式中去學習有什麼相關的權限設定可以用

本文透過 IPTABLES/EBTABLES 的規則與 Docker Container 的環境來觀察不同情況下的封包流向，主要是幫線上議程進行的重點整理，主要內容都在影片中。

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

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

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