你好，我是張磊。我今天分享的主題是：小鯨魚大事記之塵埃落定。

在上一次的分享中我提到，伴隨著 Docker 公司一手打造出來的容器技術(shù)生態(tài)在云計算市場中站穩(wěn)了腳跟，圍繞著 Docker 項目進行的各個層次的集成與創(chuàng)新產(chǎn)品，也如雨后春筍般出現(xiàn)在這個新興市場當(dāng)中。而 Docker 公司，不失時機地發(fā)布了Docker Compose、Swarm 和Machine“三件套”，在重新定義 PaaS 的方向上走出了最關(guān)鍵的一步。

這段時間，也正是 Docker 生態(tài)創(chuàng)業(yè)公司們的春天，大量圍繞著Docker 項目的網(wǎng)絡(luò)、存儲、監(jiān)控、CI/CD，甚至 UI 項目紛紛出臺，也涌現(xiàn)出了很多 Rancher、Tutum 這樣在開源與商業(yè)上均取得了巨大成功的創(chuàng)業(yè)公司。

在 2014~2015 年間，整個容器社區(qū)可謂熱鬧非凡。

這令人興奮的繁榮背后，卻浮現(xiàn)出了更多的擔(dān)憂。這其中最主要的負(fù)面情緒，是對 Docker 公司商業(yè)化戰(zhàn)略的種種顧慮。

事實上，很多從業(yè)者也都看得明白，Docker 項目此時已經(jīng)成為Docker 公司一個商業(yè)產(chǎn)品。而開源，只是 Docker 公司吸引開發(fā)者群體的一個重要手段。不過這么多年來，開源社區(qū)的商業(yè)化其實都是類似的思路，無非是高不高調(diào)、心不心急的問題罷了。

而真正令大多數(shù)人不滿意的是，Docker 公司在 Docker 開源項目的發(fā)展上，始終保持著絕對的權(quán)威和發(fā)言權(quán)，并在多個場合用實際行動挑戰(zhàn)到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微軟）的切身利益。

那么，這個時候，大家的不滿也就不再是在 GitHub 上發(fā)發(fā)牢騷這么簡單了。

相信很多容器領(lǐng)域的老玩家們都聽說過，Docker 項目剛剛興起時，Google也開源了一個在內(nèi)部使用多年、經(jīng)歷過生產(chǎn)環(huán)境驗證的 Linux 容器：lmctfy（Let Me Container That For You）。

然而，面對 Docker 項目的強勢崛起，這個對用戶沒那么友好的Google 容器項目根本沒有招架之力。所以，知難而退的 Google 公司，向 Docker 公司表示了合作的愿望：關(guān)停這個項目，和 Docker 公司共同推進一個中立的容器運行時（container runtime）庫作為 Docker 項目的核心依賴。

不過，Docker 公司并沒有認(rèn)同這個明顯會削弱自己地位的提議，還在不久后，自己發(fā)布了一個容器運行時庫 Libcontainer。這次匆忙的、由一家主導(dǎo)的、并帶有戰(zhàn)略性考量的重構(gòu)，成了Libcontainer 被社區(qū)長期詬病代碼可讀性差、可維護性不強的一個重要原因。

至此，Docker 公司在容器運行時層面上的強硬態(tài)度，以及Docker 項目在高速迭代中表現(xiàn)出來的不穩(wěn)定和頻繁變更的問題，開始讓社區(qū)叫苦不迭。

這種情緒在 2015 年達(dá)到了一個小高潮，容器領(lǐng)域的其他幾位玩家開始商議“切割”Docker 項目的話語權(quán)。而“切割”的手段也非常經(jīng)典，那就是成立一個中立的基金會。

于是，2015 年 6 月 22 日，由 Docker 公司牽頭，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司將 Libcontainer 捐出，并改名為 RunC 項目，交由一個完全中立的基金會管理，然后以 RunC 為依據(jù)，大家共同制定一套容器和鏡像的標(biāo)準(zhǔn)和規(guī)范。

這套標(biāo)準(zhǔn)和規(guī)范，就是 OCI（ Open Container Initiative ）。OCI 的提出，意在將容器運行時和鏡像的實現(xiàn)從 Docker 項目中完全剝離出來。這樣做，一方面可以改善 Docker 公司在容器技術(shù)上一家獨大的現(xiàn)狀，另一方面也為其他玩家不依賴于 Docker 項目構(gòu)建各自的平臺層能力提供了可能。

不過，不難看出，OCI 的成立更多的是這些容器玩家出于自身利益進行干涉的一個妥協(xié)結(jié)果。所以，盡管 Docker 是 OCI 的發(fā)起者和創(chuàng)始成員，它卻很少在 OCI 的技術(shù)推進和標(biāo)準(zhǔn)制定等事務(wù)上扮演關(guān)鍵角色，也沒有動力去積極地推進這些所謂的標(biāo)準(zhǔn)。

這，也正是迄今為止 OCI 組織效率持續(xù)低下的根本原因。

眼看著 OCI 并沒能改變 Docker 公司在容器領(lǐng)域一家獨大的現(xiàn)狀，Google 和 RedHat 等公司于是把與第二把武器擺上了臺面。

Docker 之所以不擔(dān)心 OCI 的威脅，原因就在于它的 Docker 項目是容器生態(tài)的事實標(biāo)準(zhǔn)，而它所維護的 Docker 社區(qū)也足夠龐大。可是，一旦這場斗爭被轉(zhuǎn)移到容器之上的平臺層，或者說PaaS 層，Docker 公司的競爭優(yōu)勢便立刻捉襟見肘了。

在這個領(lǐng)域里，像 Google 和 RedHat 這樣的成熟公司，都擁有著深厚的技術(shù)積累；而像CoreOS 這樣的創(chuàng)業(yè)公司，也擁有像 Etcd 這樣被廣泛使用的開源基礎(chǔ)設(shè)施項目。

可是 Docker 公司呢？它卻只有一個 Swarm。

所以這次，Google、RedHat 等開源基礎(chǔ)設(shè)施領(lǐng)域玩家們，共同牽頭發(fā)起了一個名為CNCF（Cloud Native Computing Foundation）的基金會。這個基金會的目的其實很容易理解：它希望，以 Kubernetes 項目為基礎(chǔ)，建立一個由開源基礎(chǔ)設(shè)施領(lǐng)域廠商主導(dǎo)的、按照獨立基金會方式運營的平臺級社區(qū)，來對抗以 Docker 公司為核心的容器商業(yè)生態(tài)。

而為了打造出這樣一個圍繞 Kubernetes 項目的“護城河”，CNCF社區(qū)就需要至少確保兩件事情：

1. Kubernetes 項目必須能夠在容器編排領(lǐng)域取得足夠大的競爭優(yōu)勢；

2. CNCF 社區(qū)必須以 Kubernetes 項目為核心，覆蓋足夠多的場景。

我們先來看看 CNCF 社區(qū)如何解決 Kubernetes 項目在編排領(lǐng)域的競爭力的問題。

在容器編排領(lǐng)域，Kubernetes 項目需要面對來自Docker 公司和 Mesos 社區(qū)兩個方向的壓力。不難看出，Swarm 和 Mesos 實際上分別從兩個不同的方向講出了自己最擅長的故事：Swarm 擅長的是跟 Docker 生態(tài)的無縫集成，而 Mesos 擅長的則是大規(guī)模集群的調(diào)度與管理。

這兩個方向，也是大多數(shù)人做容器集群管理項目時最容易想到的兩個出發(fā)點。也正因為如此，Kubernetes 項目如果繼續(xù)在這兩個方向上做文章恐怕就不太明智了。

所以這一次，Kubernetes 選擇的應(yīng)對方式是：Borg。

如果你看過 Kubernetes 項目早期的 GitHubIssue 和 Feature 的話，就會發(fā)現(xiàn)它們大多來自于Borg 和 Omega 系統(tǒng)的內(nèi)部特性，這些特性落到 Kubernetes項目上，就是 Pod、Sidecar 等功能和設(shè)計模式。

這就解釋了，為什么 Kubernetes 發(fā)布后，很多人“抱怨”其設(shè)計思想過于“超前”的原因：Kubernetes 項目的基礎(chǔ)特性，并不是幾個工程師突然“拍腦袋”想出來的東西，而是Google公司在容器化基礎(chǔ)設(shè)施領(lǐng)域多年來實踐經(jīng)驗的沉淀與升華。這，正是 Kubernetes 項目能夠從一開始就避免同 Swarm 和 Mesos 社區(qū)同質(zhì)化的重要手段。

于是，CNCF 接下來的任務(wù)就是，如何把這些先進的思想通過技術(shù)手段在開源社區(qū)落地，并培育出一個認(rèn)同這些理念的生態(tài)？這時，RedHat 就發(fā)揮了重要作用。

當(dāng)時，Kubernetes 團隊規(guī)模很小，能夠投入的工程能力也十分緊張，而這恰恰是 RedHat 的長處。更難得的是，RedHat 是世界上為數(shù)不多的、能真正理解開源社區(qū)運作和項目研發(fā)真諦的合作伙伴。

所以，RedHat 與 Google 聯(lián)盟的成立，不僅保證了 RedHat 在 Kubernetes 項目上的影響力，也正式開啟了容器編排領(lǐng)域“三國鼎立”的局面。

這時，我們再重新審視容器生態(tài)的格局，就不難發(fā)現(xiàn) Kubernetes 項目、Docker 公司和Mesos 社區(qū)這三大玩家的關(guān)系已經(jīng)發(fā)生了微妙的變化。

其中，Mesos 社區(qū)與容器技術(shù)的關(guān)系，更像是“借勢”，而不是這個領(lǐng)域真正的參與者和領(lǐng)導(dǎo)者。這個事實，加上它所屬的 Apache 社區(qū)固有的封閉性，導(dǎo)致了Mesos 社區(qū)雖然技術(shù)最為成熟，卻在容器編排領(lǐng)域鮮有創(chuàng)新。

這也是為何，Google 公司很快就把注意力轉(zhuǎn)向了動作更加激進的Docker 公司。

有意思的是，Docker 公司對 Mesos 社區(qū)也是類似的看法。所以從一開始，Docker 公司就把應(yīng)對 Kubernetes 項目的競爭擺在了首要位置：一方面，不斷強調(diào)“Docker Native”的“重要性”，另一方面，與 Kubernetes 項目在多個場合進行了直接的碰撞。

不過，這次競爭的發(fā)展態(tài)勢，很快就超過了 Docker 公司的預(yù)期。

Kubernetes 項目并沒有跟 Swarm 項目展開同質(zhì)化的競爭，所以“Docker Native”的說辭并沒有太大的殺傷力。相反地，Kubernetes 項目讓人耳目一新的設(shè)計理念和號召力，很快就構(gòu)建出了一個與眾不同的容器編排與管理的生態(tài)。

就這樣，Kubernetes 項目在 GitHub 上的各項指標(biāo)開始一騎絕塵，將 Swarm 項目遠(yuǎn)遠(yuǎn)地甩在了身后。

有了這個基礎(chǔ)，CNCF 社區(qū)就可以放心地解決第二個問題了。

在已經(jīng)囊括了容器監(jiān)控事實標(biāo)準(zhǔn)的 Prometheus 項目之后，CNCF社區(qū)迅速在成員項目中添加了 Fluentd、OpenTracing、CNI 等一系列容器生態(tài)的知名工具和項目。

而在看到了 CNCF 社區(qū)對用戶表現(xiàn)出來的巨大吸引力之后，大量的公司和創(chuàng)業(yè)團隊也開始專門針對 CNCF 社區(qū)而非 Docker 公司制定推廣策略。

面對這樣的競爭態(tài)勢，Docker 公司決定更進一步。在 2016 年，Docker 公司宣布了一個震驚所有人的計劃：放棄現(xiàn)有的 Swarm 項目，將容器編排和集群管理功能全部內(nèi)置到 Docker 項目當(dāng)中。

顯然，Docker 公司意識到了 Swarm 項目目前唯一的競爭優(yōu)勢，就是跟 Docker 項目的無縫集成。那么，如何讓這種優(yōu)勢最大化呢？那就是把 Swarm 內(nèi)置到Docker 項目當(dāng)中。

實際上，從工程角度來看，這種做法的風(fēng)險很大。內(nèi)置容器編排、集群管理和負(fù)載均衡能力，固然可以使得 Docker 項目的邊界直接擴大到一個完整的 PaaS項目的范疇，但這種變更帶來的技術(shù)復(fù)雜度和維護難度，長遠(yuǎn)來看對 Docker 項目是不利的。

不過，在當(dāng)時的大環(huán)境下，Docker 公司的選擇恐怕也帶有一絲孤注一擲的意味。

而Kubernetes 的應(yīng)對策略則是反其道而行之，開始在整個社區(qū)推進“民主化”架構(gòu)，即：從API 到容器運行時的每一層，Kubernetes 項目都為開發(fā)者暴露出了可以擴展的插件機制，鼓勵用戶通過代碼的方式介入到Kubernetes 項目的每一個階段。

Kubernetes 項目的這個變革的效果立竿見影，很快在整個容器社區(qū)中催生出了大量的、基于Kubernetes API 和擴展接口的二次創(chuàng)新工作，比如：

* 目前熱度極高的微服務(wù)治理項目 Istio；

* 被廣泛采用的有狀態(tài)應(yīng)用部署框架 Operator；

* 還有像 Rook 這樣的開源創(chuàng)業(yè)項目，它通過 Kubernetes的可擴展接口，把 Ceph 這樣的重量級產(chǎn)品封裝成了簡單易用的容器存儲插件。

就這樣，在這種鼓勵二次創(chuàng)新的整體氛圍當(dāng)中，Kubernetes 社區(qū)在 2016 年之后得到了空前的發(fā)展。更重要的是，不同于之前局限于“打包、發(fā)布”這樣的 PaaS 化路線，這一次容器社區(qū)的繁榮，是一次完全以 Kubernetes 項目為核心的“百花爭鳴”。

面對 Kubernetes 社區(qū)的崛起和壯大，Docker 公司也不得不面對自己豪賭失敗的現(xiàn)實。但在早前拒絕了微軟的天價收購之后，Docker 公司實際上已經(jīng)沒有什么回旋余地，只能選擇逐步放棄開源社區(qū)而專注于自己的商業(yè)化轉(zhuǎn)型。

所以，從 2017 年開始，Docker 公司先是將 Docker 項目的容器運行時部分 Containerd 捐贈給 CNCF 社區(qū)，標(biāo)志著 Docker 項目已經(jīng)全面升級成為一個 PaaS 平臺；緊接著，Docker 公司宣布將 Docker 項目改名為 Moby，然后交給社區(qū)自行維護，而 Docker 公司的商業(yè)產(chǎn)品將占有Docker 這個注冊商標(biāo)。

Docker 公司這些舉措背后的含義非常明確：它將全面放棄在開源社區(qū)同 Kubernetes 生態(tài)的競爭，轉(zhuǎn)而專注于自己的商業(yè)業(yè)務(wù)，并且通過將 Docker 項目改名為Moby 的舉動，將原本屬于Docker 社區(qū)的用戶轉(zhuǎn)化成了自己的客戶。

2017 年 10 月，Docker 公司出人意料地宣布，將在自己的主打產(chǎn)品 Docker 企業(yè)版中內(nèi)置Kubernetes 項目，這標(biāo)志著持續(xù)了近兩年之久的“編排之爭”至此落下帷幕。

2018 年 1 月 30 日，RedHat 宣布斥資 2.5 億美元收購 CoreOS。

2018 年 3 月 28 日，這一切紛爭的始作俑者，Docker 公司的 CTO Solomon Hykes 宣布辭職，曾經(jīng)紛紛擾擾的容器技術(shù)圈子，到此塵埃落定。

總結(jié)

容器技術(shù)圈子在短短幾年里發(fā)生了很多變數(shù)，但很多事情其實也都在情理之中。就像 Docker 這樣一家創(chuàng)業(yè)公司，在通過開源社區(qū)的運作取得了巨大的成功之后，就不得不面對來自整個云計算產(chǎn)業(yè)的競爭和圍剿。而這個產(chǎn)業(yè)的壟斷特性，對于 Docker 這樣的技術(shù)型創(chuàng)業(yè)公司其實天生就不友好。

在這種局勢下，接受微軟的天價收購，在大多數(shù)人看來都是一個非常明智和實際的選擇?？墒荢olomon Hykes 卻多少帶有一些理想主義的影子，既然不甘于“寄人籬下”，那他就必須帶領(lǐng)Docker 公司去對抗來自整個云計算產(chǎn)業(yè)的壓力。

只不過，Docker 公司最后選擇的對抗方式，是將開源項目與商業(yè)產(chǎn)品緊密綁定，打造了一個極端封閉的技術(shù)生態(tài)。而這，其實違背了 Docker 項目與開發(fā)者保持親密關(guān)系的初衷。相比之下，Kubernetes 社區(qū)，正是以一種更加溫和的方式，承接了 Docker 項目的未盡事業(yè)，即：以開發(fā)者為核心，構(gòu)建一個相對民主和開放的容器生態(tài)。

這也是為何，Kubernetes 項目的成功其實是必然的。

現(xiàn)在，我們很難想象如果 Docker 公司最初選擇了跟Kubernetes 社區(qū)合作，如今的容器生態(tài)又將會是怎樣的一番景象。不過我們可以肯定的是，Docker 公司在過去五年里的風(fēng)云變幻，以及Solomon Hykes 本人的傳奇經(jīng)歷，都已經(jīng)在云計算的長河中留下了濃墨重彩的一筆。

思考題

你如何評價 Solomon Hykes 在 Docker 公司發(fā)展歷程中的所作所為？你又是否看好 Docker 公司在今后的發(fā)展呢？

歡迎你給我留言，也歡迎分享給更多的朋友一起閱讀。

文章回復(fù)：

侯操宇

寫的真好，在線追劇既視感

2018-08-31

Cloud*

solomon很有遠(yuǎn)見，docker是一個小而美的產(chǎn)品，只有獨立存在可能才能被認(rèn)識，加入微軟，可能就只能成為微軟眾多產(chǎn)品中不知名的一員，久而久之會被人淡忘，對于未來，我相信docker的前景是好的，k8s雖然很強大，但主流也是采用docker的容器規(guī)范，這只會更好，不會淘汰。

2018-08-31

作者回復(fù)

遺憾的是，如今的docker已經(jīng)不是小而美了。有興趣可以對比一下docker1.12和現(xiàn)在的doc

ker容器啟動速度。

2018-08-31

pllsxyc

作為一個直男也覺得老師聲音很好聽是怎么回事????

2018-08-31

作者回復(fù)

受寵若驚！

2018-08-31

dancer

感謝作者在講述一個技術(shù)之前，能繪聲繪色介紹這個技術(shù)產(chǎn)生的由來，超贊！

2018-08-31

作者回復(fù)

了解了背景和發(fā)展，對后面理解 為什么這么設(shè)計 其實幫助很大。開源項目千萬不可拿過來蒙頭讀源碼，這沒有任何意義。

2018-08-31

sun

磊哥也是一個被程序員耽誤了的武俠小說作家，像看小說一樣學(xué)kubernetes，我們讀者是幸運的??

2018-09-02

llitfkitfk@dockone.io

docker適合個人使用

k8s適合企業(yè)使用

docker安裝簡單

k8s安裝復(fù)雜

docker像屌絲開的車

k8s像土豪開的車

2018-09-09

stefli

Rancher也有內(nèi)置的容器管理與編排工具，叫Cattle？比較小眾，會有怎樣的發(fā)展。現(xiàn)在看來是k8s一家獨大。

2018-09-05

作者回復(fù)

其他家的東西都會變成kubernetes 或者kubernetes的插件或集成。所以kubernetes 的作用類似于linux ，它不會擠占上層的空間，也不存在一家獨大的說法。能賣錢的，是上面的東東。

2018-09-06

大老楊

感覺朗讀的特別有感情

2018-09-05

作者回復(fù)

因為作者對技術(shù)心中充滿愛……

2018-09-05

特里王

寫得很好，有一種容器和容器編排界劇集的即視感。還是第一次看到如此深入的容器編排業(yè)界背景故事解讀。聽過 runc 原來是早期 Docker 開源的 libcontainer 。早期使用LXC Docker 是痛苦的，進程生命周期控制都得借助于三方工具。由于和傳統(tǒng)虛擬機存在巨大差異（不同的虛擬化技術(shù)），大部分開發(fā)人員使用者認(rèn)知又不夠，當(dāng)時作為 DevOops lead 要支持他們實在是痛苦。后來讓大部分人轉(zhuǎn) Vagrant + VirtualBox 去了。后來一段時間不太關(guān)注容器技術(shù)本身，但一直關(guān)注 k8s 到 v1.7 突然發(fā)力爆發(fā)，所在的創(chuàng)業(yè)公司（現(xiàn)在已經(jīng)被 SFDC 收購）開發(fā)了基于 k8s 的產(chǎn)品才開始重拾。學(xué)習(xí)近一年，基本把基礎(chǔ)架構(gòu)、網(wǎng)絡(luò)搞明白了，也算是 specific knowledge 和技能樹，具有不可替代性，無心插柳?，F(xiàn)在已經(jīng)開始研究IstioKnative 了，這兩個的理念居然和敝司 API-led Application Network 的理念不謀而合??

2018-10-05

張少坡

有幾個概念不是很明白，有點混亂，麻煩介紹下關(guān)系:docker與containerd,libcontainer,runc,oci,cri,cni等等這類的標(biāo)準(zhǔn)，謝謝。

2018-09-07

作者回復(fù)

docker - containerd - runc - OCI格式的容器

CRI CNI CSI都是kubernetes 的接口，全會講到。

libcontainer是containerd的前身，現(xiàn)在不提了

2018-09-07

blackpiglet

個人認(rèn)為 Docker 未來的發(fā)展也不會很差，當(dāng)然和大紅大紫的時候是比不了。畢竟 docker 現(xiàn)在就是事實上的容器標(biāo)準(zhǔn)，在此基礎(chǔ)上做企業(yè)的咨詢和解決方案服務(wù)，還是很有說服力的。不過完全切割開源和商業(yè)，感覺還是有點可惜。

2018-08-31

作者回復(fù)

沒錯，docker公司其實已經(jīng)起來了，只不過這次以不一樣的方式

2018-08-31

小小笑兒

Docke 公司這些舉措背后的含義非常明確：

這里的Docker誤寫作Docke了。

我覺得Docker公司今后的發(fā)展可能更多是圍繞著服務(wù)維護這塊來進行盈利了，它好像沒有了更多的競爭優(yōu)勢。

有個問題想請問下:libcontainer和containerd有啥關(guān)系？

作者回復(fù)

作用相同，前后繼承關(guān)系

2018-08-31

Backkom

Docker開源版改名為moby，大家日常交流似乎還是docker，慣性了吧

2018-08-31

作者回復(fù)

畢竟就是要這個效果

2018-08-31

jinbing

MS在這場容器大戰(zhàn)中扮演了什么樣的角色?

2018-10-09

作者回復(fù)

坐收漁翁之利，azure強勢崛起

2018-10-10

米志遠(yuǎn)

寫的太好了，引人入勝，雖然我不是做開發(fā)的，我做售前的，但是文章讀起來一點都不費力，反而閱讀越有味，更加期待后面的內(nèi)容。

2018-10-01

參悟

1.docker的創(chuàng)新，擊敗CF率先抓住容器化市場，是它前期獲得的巨大成功?？伤鼌s低估了Google這位科技巨頭深藏不露的技術(shù)實力和戰(zhàn)略眼光。也可以說docker在paas生態(tài)的野心過早表現(xiàn)，露出了馬腳被Google加快重視和反擊步伐。

2.docker的商業(yè)化道路，個人并不看好，主要是因為云計算基礎(chǔ)設(shè)施儼然形成壟斷，其潛在的客戶群體，并不能單純脫離這些基礎(chǔ)設(shè)施。其二docker技術(shù)雖然新穎，但面對這些科技巨頭也未能形成壁壘。剩下的市場雖能自足，但不能滿足docker當(dāng)初的胃口和野心。

2018-09-07

一步

剛剛看到一個新聞，google把k8s的控制權(quán)完全交給CNCF了，這背后有什么故事嗎？這個舉措意義是什么呢？

2018-09-06

作者回復(fù)

這個新聞標(biāo)題有點問題。正確的說法是，kubernetes 項目的集成環(huán)境正式跟GCE解除綁定。至于控制權(quán)，老早就不是google一家說了算。redhat了解一下。

2018-09-06

已經(jīng)打好水，搬好板凳，坐等k8s的大顯身手了。

2018-09-01

作者回復(fù)

別急，容器技術(shù)的基礎(chǔ)還是要打牢的

2018-09-01

趙沖

有點害怕看到“總結(jié)”二字，正在意猶未盡呢……好在，后續(xù)更精彩^ _ ^

2018-09-01

shupian418

你值得擁有。