bg original

个人介绍

Agenda

  1. Kubernetes 为何而生
    • Swarm, Mesos, Kubernetes
  2. Kubernetes 的架构
    • Pod
    • 部署架构和逻辑架构
    • API Spec Object
    • 架构优劣

Kubernetes 为何而生

  • 云发展到一个新阶段
    • 按需的资源
    • 对应用无侵入

      用户从关注资源的运维转向关注应用的开发运维成本

  • 容器的普及奠定了基础
    • 应用安装包标准化
    • 进程管理标准化

用户需要一套系统来管理大规模的容器

容器编排系统应运而生

我们需要一种 面向应用（Application Oriented） 的系统来降低服务端应用的开发部署和运维成本

We wanted people to be able to program for the data center just like they program for their laptop —Ben Hindman

我们再引申一下，从开发延伸到部署运维

We wanted people to be able to manager app for the data center just like they manager app on their laptop

Swarm, Mesos, Kubernetes

  1. Docker Swarm
  2. Mesos
  3. Borg, Omega, and Kubernetes

Docker Swarm

个人介绍（作者介绍） - 图2
  • 去中心化
  • 组件内置
  • 配置简易

Mesos

define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks

Mesos

个人介绍（作者介绍） - 图3
  • 资源共享
  • 编程框架
  • 分布式调度

Kubernetes

Kubernetes is not a mere “orchestration system”; it eliminates the need for orchestration. The technical definition of “orchestration” is execution of a defined workflow: do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive current state towards the provided desired state. It shouldn’t matter how you get from A to C: make it so.

Borg, Omega, and Kubernetes

  • Borg: Container,BatchJob&Service
  • Omega: State store,Multi control-plane
  • Kubernetes: ApiServer,Pod,Network,Storage,OpenSource

Swarm vs Mesos vs Kubernetes

Kubernetes - 始于编排而超越编排

  1. Kubernetes 的 Pod
  2. Kubernetes 的部署架构
  3. Kubernetes 的逻辑架构

从容器角度看 Pod

  1. 启动 pause 容器
    1. docker run -d --net=none --name pause busybox sleep 999999
  2. 通过 CNI 创建网络，然后移动到 pause 的 netns
  3. 启动业务容器，关联到 pause
    1. docker run -d --net=container:pause --name web nginx
    2. docker run -d --net=container:pause --name sidecar mysidecar

从容器角度看 Pod

个人介绍（作者介绍） - 图4
  1. 共享网络
  2. 共享 Volume
  3. 共享 IPC

Pod Spec

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: nginx
  5.   labels:
  6.     app: web
  7. spec:
  8.   containers:
  9.   - name: nginx
  10.     image: nginx:1.7.9
  11.     ports:
  12.     - containerPort: 80
  13.   - name: sidecar
  14.     image: mysidecar

个人介绍（作者介绍） - 图5

Kubernetes 逻辑架构

  1. Declare，Observe，React
  2. 一个状态存储
  3. 多个控制器

个人介绍（作者介绍） - 图6

Pod 的创建流程

个人介绍（作者介绍） - 图7

Kubernetes 中的 API Spec Object

  • Core
    • Pod/Container/Volume
    • Service 一组 Pod 对外提供能力的抽象
  • Apps
    • Replica: 控制 Pod 的副本
    • Deployment: 控制 Replica 的版本（滚动升级）
    • DaemonSet: 绑定 Pod 和 Node 关系
    • StatefulSet: 控制 Pod 的网络标志以及存储
  1. Autoscaling: HPA 根据监控条件控制 Deployment 的副本数属性

Kubernetes 的架构优势

  1. 自愈 （最终一致）
  2. 组合 （低级组件组合成高级组件）
  3. 面向未来 （API 定义目标，而不是过程）

一种面向未来的 Spec 设想

  1. apiVersion: vx
  2. kind: ServiceSLA
  3. metadata:
  4.   name: myservice-sla
  5. agreement:
  6.   success: 999
  7.   averageLatency: 200ms
  8.   cost: x$/h
  9.   selector:
  10.     app: myapp

Kubernetes 的架构劣势

  1. 同步或者依赖操作
  2. 非状态操作

Kubernetes 开放式问题

  1. 配置管理
  2. 服务依赖

相关资料

==Q&A==

about

bg original