今天我要带给大家的是2018年底，在西雅图举办的Kubecon的一场分享，来自谷歌K8s团队的工程师Saad Ali分享的《Kubernetes设计原则》。这场会议虽然已经过去一年多了，但是我觉得本会议的内容非常值得学习，我们大都知道K8s是如何工作的，但是本文带我们了解k8s背后的设计原则，以及为什么要这样设计。
对于跨云和本地环境在分布式系统上管理和部署工作负载，Kubernetes很快变得不可或缺。
虽然现在大多数人都熟悉如何使用Kubernetes，但很少有人知道其背后的“为什么”？为什么Kubernetes API看起来是这样的？为什么Kubernetes组件仅通过Kubernetes API相互交互？当您可以轻松地直接从pod引用卷时，为什么会有PersistentVolumeClaim对象？
Skaffold is a command line tool that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application. It also provides building blocks and describe customizations for a CI/CD pipeline.
git clone and skaffold runskaffold run end-to-end or just part of skaffold stages from build to deployment in your CI/CD systemTo keep Skaffold up to date, update checks are made to Google servers to see if a new version of Skaffold is available.
You can turn this update check off by following these instructions.
Your use of this software is subject to the Google Privacy Policy
For the latest stable release download and place it in your PATH:
https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
Run these commands to download and place the binary in your /usr/local/bin folder:
curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/binFor the latest bleeding edge build, download and place it in your PATH:
https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64
Run these commands to download and place the binary in your /usr/local/bin folder:
curl -Lo skaffold https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
Skaffold simplifies your development workflow by organizing common development stages into one simple command. Every time you run skaffold dev, the system
What’s more, the pluggable architecture is central to Skaffold’s design, allowing you to use the tool you prefer in each stage. Also, Skaffold’s profiles feature grants you the freedom to switch tools as you see fit depending on the context.
For example, if you are coding on a local machine, you can configure Skaffold to build artifacts with local Docker daemon and deploy them to minikube using kubectl, the Kubernetes command-line interface and when you finalize your design, you can switch to the production profile and start building with Google Cloud Build and deploy with Helm.
Skaffold supports the following tools:
kubectl)
Besides the above steps, skaffold also automatically manages the following utilities for you:
kubectl port-forwardDocumentation for latest release: https://skaffold.dev
Documentation for latest build: https://skaffold-latest.firebaseapp.com
Kubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。
Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。
Kubernetes is the cloud’s breakout success story. It’s gone from nothing to the application development equivalent of a superstar in only a few years, a rapid growth that’s left developers looking for better ways to build and manage Kubernetes-hosted applications.
There have been plenty of workarounds and extensions. Tools such as Helm make it easy to deploy resources to clusters, whereas CNAB (Cloud Native Application Bundle) wraps up applications and all their dependencies ready for deployment. At a lower level, services such as Draft help design and build basic services. You can build code and deploy it using familiar containers, and you can quickly assemble elements into Kubernetes applications. You can even automate management with Azure Kubernetes Services.
Telepresence使你可以通过从Kubernetes环境到本地进程的代理数据在本地调试Kubernetes集群。Telepresence能够为你的本地代码提供对Kubernetes服务和AWS/GCP资源的访问，因为它将部署到集群中。使用Telepresence，Kubernetes会将本地代码视为集群中的普通容器。
本文根据美团基础架构部/弹性策略团队负责人涂扬在2019 QCon（全球软件开发大会）上的演讲内容整理而成。本文涉及到的Kubernetes集群管理技术，美团相关的技术实践可参考此前发布的相关文章。
HULK是美团的容器集群管理平台。在HULK之前，美团的在线服务大部分部署都是在VM上，在此期间，我们遇到了很大的挑战，主要包括以下两点：
因为美团很多业务都具有明显的高低峰特性，大家一般会根据最高峰的流量情况来部署机器资源，然而在业务低峰期的时候，往往用不了那么多的资源。在这种背景下，我们希望打造一个容器集群管理平台来解决上述的痛点问题，于是HULK项目就应运而生了。
【译】What are Kubernetes Pods Anyway?
最近看到了一条关于Kubernetes Pods的推特，来自了不起的Amy Codes(我真的希望这是她的真名):
虽然不是100%准确(容器并不是一个真正的东西。我们将在稍后讨论这个东东)不过它确实指出了一个令人惊奇的事实。看来确实有必要探讨一下pod和容器到底是什么。
关于Pods，Kubernetes文档提供了对Pods最好、最完整的解释，但它是用非常一般的意义编写的，使用了很多术语。但我还是建议你好好读读它，因为它比我能写的解释更好、更正确。为官方文档打call！！
许多人已经知道Linux“容器”并不是真实存在的。Linux中没有所谓的“容器”。众所周知，容器使用了Linux内核中的两个特性(命名空间和cgroups)来执行的普通进程。命名空间允许我们为进程提供一个“视图”，该视图将所有内容隐藏在这些命名空间之外，从而为进程提供自己的运行环境。这使得进程无法看到或干扰其他进程。
首先要明确一个概念，Kubernetes并不是只支持Docker这一个容器运行，我们知道Kubernetes通过CRI这个抽象层，支持除Docker之外的其他容器运行，比如rkt甚至支持客户自定义的容器运行。因此，借助CRI这个抽象层，使得Kubernetes不依赖于底层某一种具体的容器运行时实现技术，而是直接操作pod，pod内部再管理多个业务上紧密相关的用户业务容器，这种架构便于Kubernetes做扩展。这是第一个原因。
Kubernetes 的核心工作过程：
Kubernetes 实际是：高度自动化的资源控制系统，将其管理的一切抽象为资源对象，大到服务器 Node 节点，小到服务实例 Pod。
Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。
使用Kubernetes可以：
实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群：
$ kubectl create -f single-config-file.yaml
kubectl是和Kubernetes API交互的命令行程序。现在介绍一些核心概念。
在 Docker 和 Kubernetes 时代，软件开发的世界发生了怎样的变化？有可能使用这些技术一劳永逸地构建一个放之四海而皆准的架构吗？
译自：https://medium.com/@dpaunin/the-best-architecture-with-docker-and-kubernetes-myth-or-reality-77b4f8f3804d
作者/来源： Dmitriy Paunin 译者： 云技术社区/老刀IBM
在 Docker 和 Kubernetes 时代，软件开发的世界发生了怎样的变化？有可能使用这些技术一劳永逸地构建一个放之四海而皆准的架构吗？当所有东西都“打包”在容器中时，有可能统一开发和集成的过程吗？这些决策有什么要求？它们会带来什么限制？它们会让开发人员的生活变得更轻松，还是会增加不必要的复杂性？