OpenStack 2018 年終盤點

目錄

文章目錄

• 目錄
• 前言
• OpenStack 一年來的成長
• Nova
• Cinder
• Neutron
• Ironic
• Cyborg
• Octavia
• Kolla
• Magnum
• Zun
• Kuryr
• 從 OpenStack 到 OpenInfra

前言

這是最好的時代，也是最壞的時代 — — 查爾斯·約翰·赫芬姆·狄更斯《雙城記》

年關將至，閒暇之餘，回顧我與 OpenStack 的 2018。

NOTE：本文內容僅做爲我的看法，與公司及合做夥伴無關。

OpenStack 一年來的成長

首先，不妨從 OpenStack Releases Notes 回顧一下今年社區開發者們做出了哪些努力，下面列舉一些我我的而言比較驚喜的新功能。

https://releases.openstack.org/rocky/
https://releases.openstack.org/queens/

Nova

• Added support for vGPUs. Experimental feature with some caveats, but admins can now define flavors that request vGPU resources.

GPU（圖形處理單元）的 「加速」 能力在科學計算、圖形處理密集型計算、機器學習、深度學習、人工智能等高性能計算領域有着普遍的應用，Nova Libvirt Driver 支持 vGPU 無疑是爲了知足這方面的市場需求。管理員能夠經過 Flavors 來定義 vGPU 的資源特性與分辨率。

nova flavor-key <flavor-id> set resources:VGPU=1

我認爲 Nova vGPUs Support 是一個挺具備標誌性的新功能，能夠看出社區有很是積極的去適應新的技術潮流。

vGPU 的資源管理依舊是交由 OpenStack Placement 負責。Placement 是最近才從 Nova Placement API 孵化出來的新 Repo，並計劃在 Stein 版本中成爲獨立項目，指望能最終代替 nova-scheduler service。隨着 OpenStack 的定義被社區進一步升級爲「一個開源基礎設施集成引擎」，意味 OpenStack 的資源系統將會由更多外部（第三方）資源類型構成（e.g. 外部存儲資源、外部網絡資源、各種 PCI 設備）。因此，當資源類型和提供者變得多樣時，就會需求一種高度抽象且簡單統一的管理方法，讓用戶和代碼可以便捷的使用、管理整個 OpenStack 的系統資源，這就是 Placement（佈局）。

• The performance of listing instances across a multi-cell cells v2 deployment has been improved and the results are now merge sorted.
• Rescheduling during a server create or resize operation is now supported in a split-MQ multi-cell cells v2 deployment.
• Operators can now disable a cell to make sure no new instances are scheduled there. This is useful for operators to introduce new cells to the deployment and for maintenance of existing cells.

今年對 Nova Cell 的支持力度依然很大，主要改進了 Multi-Cell 的性能和可操做性，這讓 OpenStack 擁有了更增強大的彈性和可擴展性，使 OpenStack 適用於更大的集羣規模。

• Traits-based scheduling is now available for the ironic compute driver. For more details, see the ironic docs for scheduling based on traits.

Ironic 支持基於 Traits（特徵）的調度方式，該功能一樣由 OpenStack Placement 實現的 Resource traits 支持，是 Nova 支持基於 Traits 對 Compute Node 進行調度的延伸功能。Placement resource traits 是一種靈活設計，相似 「標籤」，用戶能夠創建 「標籤雲」 並決定爲某個 Resource Provider 貼上 「標籤」，是一種資源概括分類需求的輔助工具。

• The placement service now supports granular RBAC policy rules configuration.

Placement 支持 RBAC（角色訪問控制）策略規則，是成爲獨立項目前的必要手續。我我的認爲，OpenStack Placement 是很是值得關注的，它未來會逐步融匯到 OpenStack 操做的各個層面中。

Cinder

• Support for attaching a single Cinder volume to multile VM instances.

Cinder Multi-Attach 支持將同一個 Volume 掛載到多個不一樣的 VM，這是一個讓人期待已久的功能，由於討論的時間實在是太長了。Multi-Attach 最直接的價值就是支撐核心業務數據盤的高可用冗餘特性，好比說：一個 Volume 同時掛載在兩個 VM 上，當 ACTIVE VM 失聯時，能夠由另外的 PASSIVE VM 繼續訪問（RO、R/W）這個卷。多臺 VM 共享一個 Volume，在集羣場景中帶來了不少便利，相似的功能一直是雲環境中最受歡迎的功能之一。

• Support for creating a volume from a backup.
• Improved user experience when recovering from storage system failures.
• Security improvements enabled when creating volumes from signed images.
• Numerous improvements that give administrators greater control over the placement of volumes.
• Improved backup functionality and performance.

對於 Cinder，我一直比較關注它「Volume Backup and DR」的進展，這與我曾經有過雲備份與容災恢復的開發經歷有關。如今 Cinder 已經支持了從備份建立新卷，並且經過優化 cinder-backup service 使用多處理器來提高了備份的性能。另外一個值得高興的是，如今能夠經過 cinder-manage 指令來執行故障轉移以及故障恢復，避免用戶直接操做數據庫的必要。能夠看出 Cinder 在提高用戶體驗上也花費了很多精力。

另外，今年的丹佛 OpenStack PTG，Cinder 團隊還討論了關於 Cinder 項目獨立的議題，使 Cinder 成爲在沒有 Keystone 或 Nova 的場景中（e.g. K8s CSI）仍能夠獨立部署並提供服務價值的項目。這個就比較有意思了，由於這樣的議題在社區中一直都頗具爭議，有一部分社區開發者會對這些但願 「脫離」 OpenStack 體系的項目持有抵觸心理，他們認爲只有跟 OpenStack 結合得更加緊密才能產生 1+1 > 2 的效益。但隨着社區提倡了所謂的 「可組合性」 項目生態協做方式，的確有感受到討論這個話題的團隊在逐漸增多。對此，我是持保留意見的，這個咱們後面再聊。

Neutron

• OVN DNS support. ovn-controller will respond to DNS queries locally on each compute node.
• OVN distributed Floating IP support.
• OVN L3 HA support for gateway routers. Now networking-ovn makes use of the OVN embedded mechanism for L3 high availability. It will be automatically used for any router as soon as more than one gateway node is available.
• OVN supports IPv6 Router solicitation and IPv6 Periodic router advertisement support.
• OVN supports binding SR-IOV ports on OVS > 2.8 and kernel >=4.8
• Support migration from an existing ML2OVS TripleO deployment to ML2OVN TripleO deployment.

Neutron 項目的人氣一直都很高，更新的內容天然也多，我主要仍是關注 OVN 的更新動態。OVN 是 OpenvSwitch 的 SDN 控制器，做爲 OVS 的控制平面，它對於運行平臺沒有特殊的要求，只要可以運行 OVS，就能夠平滑的運行 OVN。因此 OVN 對於 OpenStack 也有很是優秀的的兼容性，Neutron 只須要添加一個 Plugin 來配置 OVN 便可實現集成。採用 OVN 會爲 Neutron 帶來一些便利，好比說：OVN 原生的網絡功能能夠替代 Neutron 的 OVS agent、L3 agent、 DHCP agent 以及 DVR，讓 Neutron 的部署架構變得更加輕巧，同時 OVN 還提供了更加高的 L3 轉發性能。

• OVN NorthBound backend database consistency mechanism, multiple workers are now completely safe to access the backend database, and any inconsistency generated by the backend not being available is quickly detected and corrected by a periodic job

惋惜的是因爲 OVS DB 不是相似 MySQL 一類的 ACID 事務型數據庫，而是一個 JSON-Base 的文件數據庫，記錄的都是一些執行命令，每次有更新或初始化都會逐條地去執行這些的指令，這種實現的併發處理性能顯然是不行的。因此 OVN 如今還只適用於小規模場景，社區有提議過把 OVS DB 換成 ETCD，但也不了了之。不過從 OVN 在 Neutron 更新列表中的比重來看，依舊挺值得關注。

• ML2 implements Quality of Service rate limits for floating IPs.

浮動 IP 也開始支持 Qos 了，Octavia 支持 VIP Qos 也得益於這個實現。

• Per TCP/UDP port forwarding on floating IP is supported. Operators can save the number of global IP addresses for floating IPs.

Port forwarding 是一個比較實用的功能，應用 iptables 規則映射，實現了 IP 複用的效果，有效的節省了浮動 IP 的浪費。是一個很省錢的功能。

Ironic

• Finished implementation of rescue mode. Users can repair instances, troubleshoot misconfigured nodes, lost SSH keys, etc.

Ironic rescue mode 類比 Nova 實現的 Rescue/Unrescue 虛擬機實例修復功能，經過指定的啓動盤啓動，進入 Rescue 模式以修復受損的系統盤，如今 Ironic 也支持經過這種方式來修復裸機實例。那些老丟失 SSH Keys 的雲管們能夠鬆一口氣了。

• Added ability to manage BIOS settings, with driver support for iRMC and iLO hardware types.

BIOS 是物理硬件加載的第一個程序，負責執行硬件初始化，擁有不少可做爲的配置選項。Ironic manage BIOS settings 爲 iLO 和 iRMC 硬件類型提供 BIOS 設置管理界面可支持衆多使用場景。好比說：配置電源管理、RAID、啓用 SR-IOV 或 DPDK 等等，對於裸機雲和 NFV 這類對硬件管理靈活性要求比較高的應用場景而言是一個很是友好的支持。

• Added a ramdisk deployment interface enabling high performance computing deployments to have diskless nodes.
• Added automatic recovery from power faults, removing a long standing headache for operators.

RAMDisk 支持在沒有安裝操做系統的裸金屬設備上經過特定的引導方式將 ramdisk 運行在內存中爲 ironic-python-agent 提供執行環境，以這種方式來控制 diskless（無磁盤節點）的裸金屬硬件設備，是大規模高性能計算部署場景的經典需求。如今不只提供了 ramdisk deployment interface 並且還支持電源故障自動修復，這些對於裸機雲來講都是很是不錯的加強。

• Added the ability to define groups of conductors and nodes, enabling operators to define specific failure or management domains.

Ironic Conductor 是 Ironic 的核心 Worker，每一個 Conductor 能夠運行多個 Drivers，Conductor 經過這些 Drivers 在硬件設備上執行操做。Conductor Group 用於劃分 Conductors，並將 Nodes 分配到 Conductor Group，以此來限制指定的 Conductors 對指定的 Nodes 擁有控制權。簡單來講這是一種劃分故障域的手段，經過將物理位置相近的 Conductors 分爲一組可以有效縮小網絡分區，提高了安全和性能。

Ironic 在這一年還真是作了很多事情，全球峯會關於裸機雲（Bare Metal Cloud）議題的熱度也很高，這跟 Ironic 部署率逐年攀升的市場反饋是成正比的。我我的感受市場對裸機、虛擬機、容器三足鼎立的格局仍是比較認同的，如今有愈來愈多的企業願意本身的雲平臺實現跨虛擬化，除了虛擬機以外，也開始直接在裸機上部署容器，這樣的雲架構會更加靈活。從 Ironic 發佈的這些新功能來看，Ironic 團隊的裸機雲藍圖也愈來愈清晰了。

Cyborg

Cyborg 是一個新發布的項目，脫胎於電信領域，旨在爲專用加速設備（e.g. GPU，FPGA，SoC，NVMe SSD）以及各種加速器實現（e.g. iNIC，IP-Sec，DPDK/SPDK，eBPF/XDP）提供通用的生命週期管理框架。

經過 Cyborg，用戶能夠發現、顯示加速器分類列表，鏈接/分離加速器實例，安裝/卸載相關驅動程序，在 NFV、人工智能等高性能計算應用場景有很大潛力。Cyborg 能夠單獨使用，也能夠與 Nova 或 Ironic 結合使用。對於前者而言，Cyborg 是 OpenStack Placement 對加速資源管理的補充；對於後者而言，Cyborg 是 Ironic 對加速硬件設備管理的補充。

以往 Nova 經過 PciDevTracker 來統計 PCI 資源（e.g. SR-IOV 網卡）數據並結合 PciPassthroughFilter 來實現 PCI 資源的調度，缺少統一的 PCI 資源管理 API，而這正是 Placement 的歷史使命。Placement 結合 Cyborg 的方案有利於解決加速設備資源統計與管理的問題。當用戶須要建立一個 vGPU 虛擬機時，由 Nova 發起建立，由 Cyborg API 提供 GPU 設備管理，由 Placement API 負責調度、統籌 vGPU 資源，三者協同合做並最終經過 PCI-Passthrough 技術將 vGPU 掛載到虛擬機。

因此，我以爲 Cyborg 項目的發佈一樣具備標誌性，它會加速推動 OpenStack 在高性能計算場景的應用，是社區佈局邊緣計算、物聯網、人工智能領域的直接反映。

Octavia

• The neutron-lbaas and neutron-lbaas-dashboard projects are now deprecated.
• Neutron-lbaas now includes a proxy plugin that forwards all API requests to the Octavia API.

Octavia 是 OpenStack 官方推薦的 LBaaS 解決方案，它比 Neutron-lbaas 具備更好的擴展性、高可用性和穩定的 API，是運營商級別的負載均衡器服務。Neutron-lbaas 已經被標記爲廢棄，但舊版本的 Neutron-lbaas 依舊能夠經過 Proxy Plugin 的方式來調用 Octavia API。

• The initial release of the Octavia dashboard for Horizon includes significantly improved load balancer detail pages and workflows compared to the, now deprecated, neutron-lbaas-dashboard.
• Octavia dashboard details pages now automatically refresh the load balancer status.
• The Octavia OpenStack client plugin now supports quotas, load balancer QoS policies, load balancer failover, listener statistics, and filtering by load balancer ID.

Octavia 有專屬的 Dashboard 和 CLI 操做入口，早期 Octavia 和 Neutron-lbaas 共用一套 UI，但具備 Octavia 特點的操做並不能體現出來。如今專門針對 Octavia 的 Dashboard 和 CLI 確定會帶來更好的用戶體驗。

• Octavia now supports provider drivers, allowing third party load balancing drivers to be integrated with the Octavia v2 API.

Neutron-lbaas 實現了不少第三方負載均衡器的 Drivers 礙於時間和人力的問題遲遲沒有遷移到 Octavia，實在很是惋惜。早前的用戶只能選擇使用 Octavia Amphorae LoadBalancer Provider 實現方式，如今 Octavia 的架構調整已經完成，能夠支持集成第三方負載均衡器 Drivers 了。對於那些由於使用第三方負載均衡器（e.g. F5）致使沒法升級至 Octavia 的用戶而言，也是一個好消息。

• Pools can have backup members, also known as 「sorry servers」, that respond when all of the members of a pool are not available.

Octavia Pool 支持設置 Backup Member，當 Pool 中全部的 Members 都失聯時，將有 Backup Member 響應，進一步提高了 LB 可用性和服務體驗。

• UDP protocol load balancing has been added to Octavia. This is useful for IoT use cases.

Octavia 開始支持 UDP 協議，UDP 協議常常被用於處理音頻、視頻數據流及其餘實時應用中的傳輸層，知足了在物聯網和邊緣計算場景中的負載均衡需求。

Kolla

• Implement minimal downtime for keystone and cinder service

Kolla 已經能夠支持 Keystone 和 Cinder 的最小停機時間的，這預設着 OpenStack 項目無縫升級的可行性，不管是對用戶仍是對運維人員來講都是一件極大的利好。

• Implement Ceph Bluestore deployment in kolla and kolla-ansible.
• Implement cephfs service
• Upgrade to ceph luminous

今年 Kolla 對 Ceph 的支持力度依舊很大，Ceph 如今已是全部 OpenStack 用戶都會考慮的分佈式存儲方案。將 Ceph 和 OpenStack 一塊兒打包部署相信會是一個很棒的用戶爽點。

• Add almanach, certmonger, ceph-nfs, ptp, rsyslog, sensu and tripleo ui image
• Add vitrage ansible role
• Support deployment of prometheus, kafka and zookeeper via kolla-ansible.
• Added new docker images in kolla for logstash, monasca, prometheus, ravd, neutron-infoblox-ipam-driver and apache storm.

Kolla 實現的原子服務容器化結合 Kolla-ansible 來完成配置管理的自動化 OpenStack 部署方案，在通過了屢次大規模生產級別部署後，已經獲得了業內普遍的承認。Kolla 如今已經成爲了國內 OpenStack 用戶首選的規模化部署方案，國內一直在爲 Kolla 做出主要貢獻的九州雲實在是功不可沒。

Magnum

Magnum 項目由 OpenStack Containers Team 開發並推出，旨在將容器編排引擎做爲 OpenStack 的首類資源，異構兼容 Kubernetes，Mesos，Swarm 等容器管理平臺，爲 OpenStack 用戶提供無縫的容器運行體驗。經過 Magnum，你能夠像建立虛擬機同樣建立一個容器集羣，透明的 COE（Container Orchestration Engine）部署及網絡調整，開箱即用。藉助於 OpenStack 服務，Magnum 還能夠額外提供 COE 不具備的多租戶認證鑑權和多租戶網絡隔離等功能。

• Add new label ‘cert_manager_api’ enabling the kubernetes certificate manager api.
• Add new labels ‘ingress_controller’ and ‘ingress_controller_role’ enabling the deployment of a Kubernetes Ingress Controller backend for clusters. Default for ‘ingress_controller’ is ‘’ (meaning no controller deployed), with possible values being ‘traefik’. Default for ‘ingress_controller_role’ is ‘ingress’.
• Update kubernetes dashboard to v1.8.3 which is compatible via kubectl proxy. Addionally, heapster is deployed as standalone deployemt and the user can enable a grafana-influx stack with the influx_grafana_dashboard_enabled label.
• Update k8s_fedora_atomic driver to the latest Fedora Atomic 27 release and run etcd and flanneld in system containers which are removed from the base OS.
• k8s_fedora_atomic clusters are deployed with RBAC support. Along with RBAC Node authorization is added so the appropriate certificates are generated.
• Embed certificates in kubernetes config file when issuing ‘cluster config’, instead of generating additional files with the certificates. This is now the default behavior. To get the old behavior and still generate cert files, pass –output-certs.
• Add ‘cloud_provider_enabled’ label for the k8s_fedora_atomic driver. Defaults to true. For specific kubernetes versions if ‘cinder’ is selected as a ‘volume_driver’, it is implied that the cloud provider will be enabled since they are combined.
• Update k8s_fedora_atomic driver to the latest Fedora Atomic 27 release and run etcd and flanneld in system containers which are removed from the base OS.

在 Kubernetes 穩坐容器編排平臺老大地位同時，Magnum 今年的更新也主要圍繞着它進行，並且還經過了 Kubernetes 社區承認的部署工具認證。若是你想經過 Kubernetes 來構建你的容器環境，那麼使用 Magnum 在 OpenStack 上部署 Kubernetes 是一個不錯的選擇。由於安全性的問題，直接在裸機上部署 Kubernetes 不見得是一個使人放心的選擇，經過 Magnum 則能夠更加靈活的選擇將 Kubernetes 部署到 「Nova」 或者 「Ironic」 上。

• In the OpenStack deployment with Octavia service enabled, the Octavia service should be used not only for master nodes high availability, but also for k8s LoadBalancer type service implementation as well.

值得一提的是，因爲 Octavia Member 對象的代碼實現是依附於 IP 而非 Instance 的，這樣的設計使其可以適用於多種不一樣的場景，而非僅限於只可以爲 OpenStack Nova Instance 提供負載均衡服務。因此 Octavia 也能夠爲 Kubernetes 的 Pods 提供外層負載均衡服務。

Zun

熬了這麼久的 Zun 項目，終於在今年發佈了 1.0，緊接着在下半年發佈了 2.0。Zun 是一個 OpenStack Container as a Service 項目，目標是經過與 Neutron、Cinder、Keystone、Kuryr 等等 OpenStack 項目協同合做以提供原生的容器管理服務。經過這種方式，將 OpenStack 原有的網絡、存儲以及身份鑑權等服務無縫的融入到容器技術體系，它容許用戶無需管理服務器或集羣便可快速地啓動、運行容器，進而確保容器可以知足用戶在安全與合規性方面的要求。

Zun 實際是 Nova Docker Driver 的替代方案，Nova Docker Driver 的缺點在於 Docker 容器和虛擬機始終沒法實現徹底統一的抽象層，經過類虛擬機方式來操做容器，不免會喪失一部分優秀的容器特性，例如容器關聯、端口映射等等。因此，簡單來講 Zun 就是獨立於 Nova 以外的 Docker 容器部署調度框架。這本應該是 Magnum 的初衷，實現容器建立和生命週期管理，把容器做爲 OpenStack 首類資源。但 Magnum 在發展的進程中已經演變成了 COEs 的部署調度管理項目，這就是 Zum 和 Magnum 的本質區別。

我我的認爲 Zun 這個項目實際上是挺尷尬的，我一直以爲把容器看成虛擬機來用根本就是一個天大的誤會，沒有編排的容器感受就缺乏了靈魂。但我是知道國內有些大企業在使用它的，因此我也很好奇 Zun 能夠在怎樣的應用場景中落地。拭目以待吧。

Kuryr

• Introduced port pools feature.
• Support for running in containers as K8s network addon.
• Introduced kuryr-daemon service.
• Introduced liveness and readiness probes for kuryr-controller.
• Added support for High Availability kuryr-controller in an Active/Passive model, enabling quick and
• transparent recovery in case kuryr-controller is lost.
• Added support for namespace isolation, lettting users isolate pods and services in different namespaces, implemented through security groups.
• Added support for multi-vif based on Kubernetes Network Custom Resource Definition De-facto Standard spec defined by the Network Plumbing Working Group, allowing multiple interfaces per pod.

Kuryr 的歷史使命就是將容器網絡與 OpenStack Neutron 對接，實現虛擬機實例、容器、外部網絡三者互通。隨着容器網絡發展出現的分歧，Kuryr 也相應的有兩個分支：kuryr-libnetwork（CNM）和 kuryr-kubernetes（CNI）。從更新列表能夠看出，今年的 Kuryr 團隊彷佛更傾向於以推動 kuryr-kubernetes 爲主。使用 Kuryr-Kubernetes 能夠讓你的 OpenStack VM 與 Kubernetes Pods 運行在同一個網絡中，並且能夠使用 Neutron 的 L3 與 Security Group 來實現網絡路由以及隔離特定的 Ports。

• Added support for health checks of the CNI daemon, letting users confirm the CNI daemon’s functionality and set limits on resources like memory, improving both stability and performance and for it to be marked as unhealthy if needed.

Kuryr CNI 根據 Kuryr Controller 分配的資源將網絡綁定到特定的 Pods 上，如今增長了一個 CNI Daemon 會有效提高運維 Kubernetes 的可擴展性。

• Added native route support enabling L7 routing via Octavia Amphorae instead of iptables, providing a more direct routing for load balancers and services.

隨着 Octavia 的成熟，愈來愈多的項目有意藉助於 Octavia Amphorae 的網絡連通性，我我的也認爲 Amphorae 帶來的這種打通網絡的能力是一個頗有想象空間的實現方式。

除了網絡以外，Kuryr 還但願能夠成爲容器與 OpenStack 之間的 Storage Bridge，支持容器訪問 Cinder 塊存儲以及 Manila 共享存儲服務。Kuryr 是 OpenStack 與容器結合的關鍵節點，值得關注。

從 OpenStack 到 OpenInfra

之因此花這麼長時間來整理今年兩個新版本 Queens 和 Rocky 的 Release Note，是由於這些都是 OpenStack 發展方向最直接體現。從宏觀角度看，我是這麼來總結的。

• Pike 版的主導的是下降運維成本
• Queens 版主導的是實現更好的易用性和操做體驗
• Rocky 版主導的是業務場景融合

以前有人說 PQR 三個版本不會有太明顯的突變，依舊會以穩定性爲主。我不贊同，經過上面的整理，咱們能夠感覺到 OpenStack 這一年在大規模部署、快速升級、高性能計算、硬件加速、裸機雲、擁抱容器以及資源管理整合方面都有不錯的表現，這些努力顯然是爲了迎接 5G 時代的物聯網、邊緣計算、電信 NFV 以及人工智能領域的業務負載。OpenStack 社區依舊在緊貼用戶需求，追隨技術潮流。正如 OpenStack 基金會首席運營官 Mark Collier 所言：「咱們如今看到的市場，是人們但願用雲作更多的事情，如機器學習、人工智能和容器等新的工做負載。」

去年我在《從 2017 OpenStack Days China 看國內雲計算的發展示狀》一文中提到：國內的 OpenStack 私有云已經正式邁入成熟階段。成熟的標誌就是用戶衝突從 「如何作雲」 向 「如何用雲」 的偏移；用戶的部署案例從測試環境向生產環境轉移；用戶託付給 OpenStack 的工做負載從非核心業務向核心業務遷移。17 年是 OpenStack 遍地開花的一年，那麼 18 年就應該是縱深挖掘行業價值、業務融合、市場更加細分的一年。簡單總結一下今年 OpenStack 給我感覺最深的變化 —— 從穩定性中解放，在應用場景中深化。

隨着整個雲計算行業的飛速發展，用戶對雲價值轉化的思考也更加複雜有深度，而不是滯留於上雲的表面。有更多的用戶會考慮 PaaS、兩地三中心容災、混合雲、多雲間數據流轉等應用場景。伴隨着行業用戶的多樣性，OpenStack 也須要爲不一樣的業務負載（e.g. 人工智能、大數據、物聯網）提供運行支撐，這些其實是用戶業務深度融合與進一步提升平臺自主性的剛性需求。用戶須要的每每是一個總體的雲解決方案，這裏面不只僅只有 IaaS，但並不是全部的技術都會在 OpenStack 社區內獲得發展。因此，社區在繼 「可組合性」 的項目協做方式以後，在今年又提出了更加完全的 OpenInfra 思想，以更 「開放」 的態度擁抱一切能夠組合的開源項目，將 OpenStack 打形成一個開源基礎設施的集成引擎。

對於從 OpenStack 到 OpenInfra 的轉變，我認爲社區是作了長足準備的。從去年的輕量級安全容器項目 Kata Container（融合了虛擬化和容器技術）、今年的 CI/CD 項目 Zuul、再到融合了 IaaS 與 PaaS 的 Airship 與邊緣計算項目 StarlingX，它們逐一成爲 OpenStack 基金會的頂級項目與 OpenStack 項目並駕齊驅，搭建出整個 Open Infrastructure 的藍圖。

Mark Collier 還說過：「OpenStack 社區主要目的是爲了解決問題，並不斷完善計算、存儲和網絡。但如今已經不只限於這些。咱們正在創建技術堆棧，但這不是一個固定的堆棧，它是一個靈活的可編程基礎設施技術棧。咱們須要將不一樣的開源項目粘合在一塊兒，而 OpenStack 社區成員已經得到了這方面的專業知識。」這段話凸顯了 OpenStack 以社區運營爲中心的管理特點，你要知道每一個社區都有本身的個性，協同社區間的合做雙贏是一項極具工程與人文追求的事業，而 OpenStack 社區正爲之付出努力，並在 OpenStack、OpenNFV、KVM、Ceph 社區之間獲得了實踐，這正是我所欽佩的。

其實我我的認爲不管是 「可組合性」 仍是 OpenInfra，這些思路都是正確的。但在實踐上卻出現了誤差。我以爲可組合的粒度應該是 OpenStack 與其餘開源項目，而非 OpenStack 下屬項目（e.g. Keystone、Cinder、Neutron）與其餘開源項目。OpenStack 內部的項目應該進一步加深緊密聯繫、互相依賴以提供更加完備而流暢的計算、存儲、網絡等基礎設備資源的服務能力，再對外提供簡易而統一的 API，以此實現開發式的 API 經濟。從上文能夠感覺到，在這一方面 Octavia 項目就是一個很棒的例子。惋惜的是，有些項目會但願謀求獨立運營，花費精力去適配諸如 Kubernets 之類的平臺，最終致使方向分散，內部撕裂，成爲 「四不像」 項目的結果。其實 OpenStack 的計算、存儲和網絡依舊存在改進的空間，例如：Nova Cell、Nova Placement、Cinder DR、Neutron DVR 等等。不知道是否有人計算過，花費了這麼多人力與時間圍繞着 OpenStack 體系構建起來的項目，再去對其餘平臺進行適配須要花費多少溝通、研發和討論的成本？這是理想與現實之間的差距，也是我認爲如今有些項目之因此變得疲軟的緣由。

固然了，這也只是部分狀況，如此龐大的開源社區，總會有各類各樣的問題。如今的 OpenStack 依舊在迸發其旺盛的生命力，依舊快速增加的國內市場就是力證。不管如何，OpenStack 在這八年間不只成爲了一個優秀的開源私有云架構，還極大推進 OpenFlow、Ceph 等開源項目的發展，甚至在全世界範圍內傳播開源、開發的思想與社區運營案例，僅憑這些 OpenStack 就是成功的。

曾經有人問我 OpenStack 之於我而言意味着什麼？我說：開源。雲的將來不會只有 OpenStack，也不會只有 Kubernetes，但卻總會有主流的開源技術，例如：KVM、Container、Ceph、OVS 以及 Cassandra，萬變不離其宗，做爲一名雲計算技術工程師，我看重的也是這些。