執行構建良好的容器會極大的影響環境的整體效能和安全性。

關於容器安全的詳細資訊，也可以參考 Rancher 的容器安全指南。以下是一些設定容器的技巧。
https://rancher.com/complete-guide-container-security

使用通用容器作業系統

在可能的情況下，你應該儘量在一個通用的容器基礎作業系統上進行標準化。

Alpine 和 BusyBox 等較小的發行版減少了容器映象的大小，並且通常具有較小的漏洞。

流行的發行版如 Ubuntu、Fedora 和 CentOS 等都經過了大量的測試，並提供了許多的功能。

從零開始的容器

如果你的微服務是一個獨立的靜態二進位制，你應該使用FROM scratch容器。

FROM scratch容器是一個官方 Docker 映象，它是空的，這樣你就可以用它來設計最小的映象。
https://hub.docker.com/_/scratch

這將具有最小的攻擊層和最小的映象。

以非特權方式執行容器程序

在可能的情況下，在容器內執行程序時使用非特權使用者。雖然容器執行時提供了隔離，但仍然可能存在漏洞和攻擊。如果容器以 root 身份執行，無意中或意外的主機掛載也會受到影響。有關為 pod 或容器配置安全上下文的詳細資訊，請參考 Kubernetes 文件。
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

定義資源限制

將 CPU 和記憶體限制應用於你的 Pod。這可以幫助管理工作節點上的資源，並避免發生故障的微服務影響其他微服務。

在標準 Kubernetes 中，您可以在名稱空間級別上設定資源限制。在 Rancher 中，您可以在專案級別上設定資源限制，它們將繼承到專案內的所有名稱空間。詳情請參考 Rancher 文件。

在設定資源配額時，如果您在專案或名稱空間上設定了任何與 CPU 或記憶體相關的內容（即限制或保留），所有容器都需要在建立期間設定各自的 CPU 或記憶體欄位。為了避免在建立工作負載期間對每個容器設定這些限制，可以在名稱空間上指定一個預設的容器資源限制。

Kubernetes 文件中有許多關於如何在容器級別和名稱空間級別設定資源限制的資料。

定義資源需求

你應該將 CPU 和記憶體需求應用到你的 pod 上。這對於通知排程器需要將你的 pod 放置在哪種型別的計算節點上，並確保它不會過度配置該節點資源至關重要。在 Kubernetes 中，你可以通過在 pod 的容器規範的資源請求欄位中定義resources.requests來設定資源需求。詳情請參考Kubernetes 文件。
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container

注意： 如果您為 pod 所部署的名稱空間設定了資源限制，而容器沒有特定的資源請求，則不允許啟動 pod。為了避免在建立工作負載時對每個容器設定這些欄位，可以在名稱空間上指定一個預設的容器資源限制。

建議在容器級別上定義資源需求，否則，排程程式會做出一些假設，這些假設可能會在叢集載入時對您的應用程式沒有幫助。

配置存活和就緒探測器

為你的容器配置存活探針和就緒探針。除非你的容器完全崩潰，否則 Kubernetes 不會知道它是不健康的，除非你建立一個可以報告容器狀態的端點或機制。或者，確保你的容器在不健康的情況下停止並崩潰。

Kubernetes 文件展示瞭如何配置存活和就緒探測器。
https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/