k8s到底做了什麼不可思義的事情以及未來2018年後將做什麼不可思義的事情？
舉個例子，在沒有Docker以前，人們在雲上蓋網站，通常會開機器，並且將所有服務(db , api , 網頁伺服器)都放在同一台機器上。
但造成的問題就是當流量大死機時，就是全死，而且你也不容易找出是那裡掛了。
但在k8s時代裡，就是將每個服務都獨立成各自的Pod(裡面有Container)，Pod的設計原則就是不需依存其他服務的存在，就成為一個pod，所以通常db會是一個pod，nginx是一個pod，前端網頁是一個pod，後端是一個pod，後台伺服是一個pod，後台是一個pod，每一支api都可以是一個pod。
這樣做很屌, 當你不知道那跟筋不對勁，在某個很少用的api寫了一個遞迴呼叫，而在某天你又不知道那跟筋不對勁，呼叫那個，而當那個api陷入遞迴呼叫時，不會再像以前一樣，因為吃掉了機器上所有的貢源，導致整個服務全部死掉。
你死掉的只是那個pod，而且你還可以讓k8s去關掉那個pod，再重啟它。
而且這個只是k8s強大功能的前菜而已。
我們在雲上運營服務，最care的還是成本。
k8s可以依照流量，動態增減機器，也幫你省下了很多錢。
而目前的主流serverless除了 AWS lambda, GCP Cloud function, Azure function之外，在k8s上目前也有多套(2018.10)正在車拚中，比較冒出頭的是kubeless，但估計只是名字取得好，推薦這個主要由台灣工程師maintain的fission，主要的好處是，出問題時，直接在issue問中文就好了，哈。
雖然三家的cloud function都不錯，但他們的設計目地，對的是全球的使用者，所以可能不太符合你的需要，例如cold start 的問題；所以你採用自已的serverless時，就可以針對這個問題做改善了。
還有搬家成本變很低，在這個 incubator 比 startup 還多的時代裡，incubator通常會跟三本柱的其中一間合作。也就是說要拿credit真的還滿容易的。而以前用了某家，如果服務要搬家，那痛苦指數真的是相當高。
但你現在可能只剩DB的部份要處理後，例如mongoDb的那一塊presisTant Image 直接clone過去，應該幾乎無痛搬家了吧。
https://kubernetes.io/docs/tasks/federation/federation-service-discovery/
cluster可以跨不同品牌的雲端伺器器，這個真的也是屌，假設有一天，你的服務在全世界火了，要知道每家雲端每個地區的賣法都是不太一樣的，以及每個區域，也不見得有機器。
例如：GCP有台灣機房，Azure有香港機房，而AWS居然有南韓。但現在為了使用者體驗，你就可以協調這些機器，不用因為被一家綁定，所以東亞只能固定連同一個地點。
當然三家都有東京，這個時候，在日本的使用者，我們就可以依照當時每一家的售價來決定要開那一家的服務。
好啦，這個想太遠，但希望有這個機會，用到這個k8s的feature啊！