Borg, Omega, and Kubernetes讀後筆記
前言
最近又讀了一遍 Borg, Omega, and Kubernetes 這篇文章，覺得這個文章寫得很好，讓我對架構設計有了進一步的認識，所以想寫一篇讀後筆記。
原文地址，還有篇中文翻譯的，這個中文翻譯感覺有的地方沒有翻譯，有的地方我有不同的理解，這裏我就以英文原版為例，參考中文翻譯來寫這篇讀後筆記。
容器管理系統的介紹
Borg was built to manage both long-running services and batch jobs, which had previously been handled by two separate systems: Babysitter and the Global Work Queue.
Borg 主要是管理長期運行的服務和批處理作業，Borg 的復雜度也是逐漸增加的，有很多定制化的東西，所以和谷歌的內部系統耦合很緊。
Omega, an offspring of Borg, was driven by a desire to improve the software engineering of the Borg ecosystem.
It applied many of the patterns that had proved successful
in Borg, but was built from the ground up to have a more consistent, principled architecture.
Omega 強調更高的一致性。
More importantly, Kubernetes
was developed with a stronger focus on the experience of developers writing applications that run in a cluster: its main design goal is to make it easy to deploy and manage complex distributed systems, while still benefiting from the improved utilization that containers enable.
這句話我還是想強調一下的，K8s 在開發的時候非常強調開發者在開發集群中應用的體驗，它的主要目標就是簡化管理和部署復雜的分布式系統，同時還能受益於容器的高利用率。
現在的大廠競爭其實就是開發者的競爭，現在越來越強調註重開發者體驗而非最終用戶體驗這個理念(其實就是 API 設計是否良好，或者說編程體驗是不是良好)。
面向應用的基礎設施
over time it became clear that the benefits of containerization go beyond merely enabling higher levels of utilization.
Containers encapsulate the application environment, abstracting away many details of machines and operating systems from the application developer and the deployment infrastructure.
Because well-designed containers and container images are scoped to a single application, managing containers means managing applications rather than machines. This shift of management APIs from machine-oriented to application oriented dramatically improves application deployment and introspection.
應用環境
One consequence is that Google has only a small number of OS versions deployed across its entire fleet of machines at any one time, and it needs only a small staff of people to maintain them and push out new versions.
容器作為管理單元
Building management APIs around containers rather than machines shifts the “primary key” of the data center from machine to application.
A common use pattern is for a pod to hold an instance
of a complex application. The major part of the application sits in one of the child containers, and other child containers run supporting functions such as log rotation or click-
log offloading to a distributed file system. Compared to combining the functionality into a single binary, this makes it easy to have different teams develop the distinct pieces of functionality, and it improves robustness (the offloading continues even if the main application gets wedged), composability (it’s easy to add a new small support service, because it operates in the private execution environment provided by its own container), and fine-grained resource isolation (each runs in its own resources, so the logging system can’t starve the main app, or vice versa).
編排只是開始，不是結束
Consistency is also achieved through common design patterns for different Kubernetes components. The idea of a reconciliation controller loop is shared throughout Borg, Omega, and Kubernetes to improve the resiliency of a system: it compares a desired state (e.g., how many pods should match a label-selector query) against the observed state (the number of such pods that it can find), and takes actions to converge the observed and desired states.Because all action is based on observation rather than a state diagram, reconciliation loops are robust to failures and perturbations: when a controller fails or restarts it simply picks up where it left off.
需要避免的事情
不要讓容器系統管理端口
不要只是標識容器：給他們標簽
註意所有權
In Kubernetes, pod-lifecycle management components such as replication controllers determine which pods
they are responsible for using label selectors, so multiple controllers might think they have jurisdiction over a single pod. It is important to prevent such conflicts through appropriate configuration choices. But the flexibility of labels has compensating advantages—for example, the separation of controllers and pods means that it is possible to “orphan” and “adopt” containers.
不要暴露裸狀態
A key difference between Borg, Omega, and Kubernetes is
in their API architectures.
一些開放並且困難的問題
配置
依賴管理
結語
A decade‘s worth of experience building container-management systems has taught us much, and we have embedded many of those lessons into Kubernetes, Google‘s most recent container-management system. Its goals are to build on the capabilities of containers to provide significant gains in programmer productivity and ease of both manual and automated system management. We hope you‘ll join us in extending and improving it.
Borg, Omega, and Kubernetes讀後筆記