關於 pod kubernetes ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://www.cncf.io/blog/2021/09/03/kubescape-the-first-open-source-tool-for-running-nsa-and-cisa-kubernetes-hardening-tests/

本篇文章是一個專案介紹文，該專案是個名為 Kubescape 的安全性掃描專案，該專案主要是用來檢驗目標 Kubernetes 是否能夠通過 NSA/CISA 等安全性檢查。

National Security Agency(NSA) 以及 Cybersecurity and Infrastructure Security Agency (CISA) 最近有發佈一個高達 52 頁的安全性指南，
該指南探討如何設立與強化 Kubernetes 叢集的安全性。
https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF

而 Kubescape 專案是一個基於 OPA(OpenPolicyAgent) 引擎的安全性檢查專案，該專案會從 Kubernetes API 取得各類型 Kubernetes 專案的資訊並且針對這些資訊去進行檢查。
檢查是基於上述 NSA/CISA 發布的安全性報告，該檢查的類別包含

1. Non-root containers
2. Immutable container filesystem
3. Building secure container images
4. Privileged containers
5. hostPID, hostIPC privileges
6. hostNetwork access
7. allowedHostPaths field
8. Protecting pod service account tokens
9. Pods in kube-system and kube-public
10. Resource policies
11. Control plane hardening
12. Encrypted secrets
13. Anonymous Requests

有興趣的可以試試看這個專案

ref: https://blog.kubecost.com/blog/kubernetes-labels/

本篇文章是一個 Kubernetes Label 介紹文， Kubernetes 的使用者一定都知道 Kubernetes 內的物件很大量依賴 Label 的使用，最基本的用法就是
Deployment 與 Pod 之間是透過 Label 與 LabelSelector 互相溝通的。

Kubernetes 提供兩種不同的方式來為資源打上標記，分別是
1. labels
2. annotations

兩者都是基於 key/value 的方式來設定，不過用途是完全不同。 Label 主要是用來提供辨識的功能，讓使用者可以透過 key/value 的方式來辨識當前的資源，就如同前述提到的 Deployment 與 Pod 的關係。
透過 Label 來標示 Pod，而 Deployment 則透過 LabelSelector 來選擇符合標準的 Pod。

Label 主要有兩大用法
1. Grouping Resource for Queries
2. Bulk Operations.

第一種用法就是前述提到的，將一群資源透過 Label 給標記起來，另外一個則是透過 kubectl 等指令操作時，可以一口氣操作多個資源，譬如
kubectl delete deployment -l environment in (dev,sit)
上述資源可以一口氣將符合 environmnet=dev 以及 environmnet=sit 的 deployment 給一次刪除。

文章中還列舉了其他介紹與學習 Labeling 概念的網站，最後還提到一個使用 Label 上要注意的相關事項
1. 不要將一些會一直改變的資料放到 Label 中
2. 沒有任何理由的話，不要輕易去修改運行資源的 Label 內容
3. Label 本身的設計不是一個 data store，所以不要將一些 Application 的重要資料給存放到 Label 上

對於 Label 這概念想要更深理解的可以參閱全文

ref: https://blog.argoproj.io/argo-workflows-2021-survey-results-d6fa890030ee
這篇是由 Argo 官方所發表的統計文章，該文章主要是探討 Argo Workflows 的使用，總共有效的問券有 60 份

你是誰
1. 32% DevOps Engineer
2. 26% Software Engineer
3. 15% Architect
4. 9% Data Engineer

使用案例(前六大項)
1. Infrastructure Automation
2. Data Processing
3. CI/CD
4. Batch Processing
5. Machine Learning
6. ETL

由於問券內容中大部分都是 DevOps 相關職缺，所以答案會偏向 Infrastructure, CI/CD 也是不太意外。

最受歡迎的功能(按照名次排序)
1. Workflow Template
2. CronWorkflows
3. API
4. Prometheus Metrics
5. Workflow Archive
6. Golang/Java/Python Clients
7. SSO
8. WebHooks
9. Workflow Reports
10. Node Offloading
11. Memoization
12. Semaphores/Mutexes

Argo 官方對於這個評比是有點經驗，本以為會更多人使用(6)與(12)，不過這些功能實際上的釋出也是相對新。

規模
1. 大部分的使用者一天會運行 10~100 個左右的 workflows
2. 有三個使用者每天會運行 1000 個以上的 workflows
3. 大部分使用者每個 workflow 運行的 pod 數量範圍為 10~100
4. 有兩個使用者每個 workflow 運行的 pod 數量超過 10,000

導入生產環境的困境
1. 有七個人表示習慣使用 Python，所以使用 YAML 語法相對困難
2. 有三個人表示需要去熟悉 Cloud-native/Container 的相關用法與概念

為什麼使用 Argo Workflows
1. 28 個人表示因為其是 Cloud Native/Kubernetes 相關專案
2. 有六個人表示 Argo Workflow 是目前最好用的 workflow 專案
3. 有五個人表示輕量與容易上手
4. 有五個人表示與 Argo CD 可以輕鬆整合無煩惱

對 Argo Workflow 有興趣的人可以參考這個專案，其還可以組合出符合 DGA 拓墣的關係圖，讓你的 job 組合變化多端

https://gigazine.net/news/20201230-kubedoom/
【TEST】DOOMで敵を倒してKubernetesのPodを強制終了させまくれる「Kube DOOM」レビュー - GIGAZINE