OpenShift在企業中的實踐筆記-第2章

OpenShift與Kubernetes的關係, 可以闡釋為: OpenShift因Kubernetes而重生, Kubernetes因OpenShift走向企業級PaaS平台.

OpenShift 4 的邏輯架構

OpenShift 4的技術架構

由下而上介紹:

• 基礎作業系統是Red Hat CoreOS, Red Hat CoreOS是一個Linux發行版, 專用於容器執行的操作系統.
• CRI-O是Kubernetes CRI(容器運行時接口)的實現, 以支持使用OCI(Open Container Initiative)兼容的運行時. CRI-O可以使用滿足CRI的任何容器運行時, 如runc(由Docker服務使用), libpod(由Podman使用)或rkt(來自CoreOS).
• Kubernetes是容器編排調度平台.
• Etcd是一個分布式鍵值存儲, Kubernetes使用它來儲存有關Kubernetes集群元數據和其它資源的配置和狀態信息.
• 自定義資源定義(CRD)是Kubernetes提供的用於擴展資源類型的接口, 自定義對象同樣儲存在Etcd中並由Kubernetes管理.
• 容器化服務(Containerized Service)實現了PaaS功能組件的以容器方式於OpenShift上運行.
• 應用程序運行時和xPaaS(Runtime and xPaaS)是可供開發人員使用的基本容器鏡像, 每個鏡像都預先配置了特定的運行時語言或數據庫. xPaaS是Red Hat中間件產品(如JBoss EAP和ActiveMQ)的一組基礎鏡像.
• DevOps工具和用戶體驗(DevOps Tool and user Experience): OpenShift提供用于管理用戶應用程序和OpenShift服務的Web UI和CLI管理工具. OpenShift的Web UI和CLI管理工具是使用REST API構建的, 可以被IDE和CI平台等外部工具使用.

OpenShift組件架構

 

OpenShift外部訪問的實現

集群外部訪問Service或Pod有5種方式:

1.Hostport

將容器的port與宿主機進行port mapping, 可以直接通過Docker實現. 優點: 易於操作. 缺點: 無法支援複雜的業務場景, 且容器間的相互訪問比較困難.

2.Nodeport

Nodeport是Service的一種類型, 將Service IP和port mapping到OpenShift集群所有節點的節點IP和隨機分配的port號(預設的範圍是30000~32767).

Nodeport與Hostport差異是, Hostport是針對一個單宿主機的一個容器; Nodeport是針對kubernetes集群而言.

3.hostnetwork

hostnetwork是pod運行的一種模式, Pod的IP和port直接綁定宿主機的IP和port, 不經過iptables和Service負載. 例如, 在OpenShift中, router就是以hostnetwork模式運行. 優點: 直接使用宿主機網路, 轉發路徑短, 性能好; 缺點: 占用節點的實際port, 無法在同一個節點同時運行相同port的兩個pod.

4.LoadBalancer

LoadBalancer也是Service的一種類型, 用於與雲平台負載均衡器結合. 

5.Ingress/Router

Ingressngress是一種負戴的實現方式, 如常用的Nginx, Haproxy等開源的反向代理負載均衡器實現對外曝露服務 . Ingress用於配置域名轉發, 並實時監控應用Pod的變化, 動態更新負載均衡器的配置文件. Ingress包含兩大主件Ingress Controller和Ingress. Ingress是一種資源對象, 聲名域名和Service對應的問題; Ingress Controller是負載均衡器, 加載Ingress動態生成負載均衡配置.

在OpenShift中, 通過Router實現Ingress的功能, 提供集群外訪問

(未完待續....)