kubernetes中文手册
  • 前言
    • 序言
  • 云原生
    • 云原生(Cloud Native)的定义
    • 云原生的设计哲学
    • Kubernetes 的诞生
    • Kubernetes 与云原生应用概览
    • 云原生应用之路 —— 从 Kubernetes 到云原生
    • 定义云原生应用
      • OAM
        • Workload
        • Component
        • Trait
        • Application Scope
        • Application Configuration
      • Crossplane
    • 云原生编程语言
      • 云原生编程语言 Ballerina
      • 云原生编程语言 Pulumi
    • 云原生的未来
  • 快速入门
    • 云原生新手入门指南
    • Play with Kubernetes
    • 快速部署一个云原生本地实验环境
    • 使用 Rancher 在阿里云上部署 Kubenretes 集群
  • 概念与原理
    • Kubernetes 架构
      • 设计理念
      • Etcd 解析
      • 开放接口
        • CRI - Container Runtime Interface(容器运行时接口)
        • CNI - Container Network Interface(容器网络接口)
        • CSI - Container Storage Interface(容器存储接口)
      • 资源对象与基本概念解析
    • Pod 状态与生命周期管理
      • Pod 概览
      • Pod 解析
      • Init 容器
      • Pause 容器
      • Pod 安全策略
      • Pod 的生命周期
      • Pod Hook
      • Pod Preset
      • Pod 中断与 PDB(Pod 中断预算)
    • 集群资源管理
      • Node
      • Namespace
      • Label
      • Annotation
      • Taint 和 Toleration(污点和容忍)
      • 垃圾收集
    • 控制器
      • Deployment
      • StatefulSet
      • DaemonSet
      • ReplicationController 和 ReplicaSet
      • Job
      • CronJob
      • Horizontal Pod Autoscaling
        • 自定义指标 HPA
      • 准入控制器(Admission Controller)
    • 服务发现与路由
      • Service
      • 拓扑感知路由
      • Ingress
        • Traefik Ingress Controller
      • Kubernetes Service API
        • Service API 简介
    • 身份与权限控制
      • ServiceAccount
      • 基于角色的访问控制(RBAC)
      • NetworkPolicy
    • 网络
      • Kubernetes 中的网络解析 —— 以 flannel 为例
      • Kubernetes 中的网络解析 —— 以 calico 为例
      • 具备 API 感知的网络和安全性管理开源软件 Cilium
        • Cilium 架构设计与概念解析
    • 存储
      • Secret
      • ConfigMap
        • ConfigMap 的热更新
      • Volume
      • 持久化卷(Persistent Volume)
      • Storage Class
      • 本地持久化存储
    • 集群扩展
      • 使用自定义资源扩展 API
      • 使用 CRD 扩展 Kubernetes API
      • Aggregated API Server
      • APIService
      • Service Catalog
    • 多集群管理
      • 多集群服务 API(Multi-Cluster Services API)
      • 集群联邦(Cluster Federation)
    • 资源调度
      • 服务质量等级(QoS)
  • 用户指南
    • 用户指南概览
    • 资源对象配置
      • 配置 Pod 的 liveness 和 readiness 探针
      • 配置 Pod 的 Service Account
      • Secret 配置
      • 管理 namespace 中的资源配额
    • 命令使用
      • Docker 用户过渡到 kubectl 命令行指南
      • kubectl 命令概览
      • kubectl 命令技巧大全
      • 使用 etcdctl 访问 Kubernetes 数据
    • 集群安全性管理
      • 管理集群中的 TLS
      • kubelet 的认证授权
      • TLS Bootstrap
      • 创建用户认证授权的 kubeconfig 文件
      • IP 伪装代理
      • 使用 kubeconfig 或 token 进行用户身份认证
      • Kubernetes 中的用户与身份认证授权
      • Kubernetes 集群安全性配置最佳实践
    • 访问 Kubernetes 集群
      • 访问集群
      • 使用 kubeconfig 文件配置跨集群认证
      • 通过端口转发访问集群中的应用程序
      • 使用 service 访问群集中的应用程序
      • 从外部访问 Kubernetes 中的 Pod
      • Cabin - Kubernetes 手机客户端
      • Lens - Kubernetes IDE/桌面客户端
      • Kubernator - 更底层的 Kubernetes UI
    • 在 Kubernetes 中开发部署应用
      • 适用于 Kubernetes 的应用开发部署流程
      • 迁移传统应用到 Kubernetes 中 —— 以 Hadoop YARN 为例
      • 使用 StatefulSet 部署用状态应用
  • 最佳实践
    • 最佳实践概览
    • 在 CentOS 上部署 Kubernetes 集群
      • 创建 TLS 证书和秘钥
      • 创建 kubeconfig 文件
      • 创建高可用 etcd 集群
      • 安装 kubectl 命令行工具
      • 部署 master 节点
      • 安装 flannel 网络插件
      • 部署 node 节点
      • 安装 kubedns 插件
      • 安装 dashboard 插件
      • 安装 heapster 插件
      • 安装 EFK 插件
    • 生产级的 Kubernetes 简化管理工具 kubeadm
      • 使用 kubeadm 在 Ubuntu Server 16.04 上快速构建测试集群
    • 服务发现与负载均衡
      • 安装 Traefik ingress
      • 分布式负载测试
      • 网络和集群性能测试
      • 边缘节点配置
      • 安装 Nginx ingress
      • 安装配置 DNS
        • 安装配置 Kube-dns
        • 安装配置 CoreDNS
    • 运维管理
      • Master 节点高可用
      • 服务滚动升级
      • 应用日志收集
      • 配置最佳实践
      • 集群及应用监控
      • 数据持久化问题
      • 管理容器的计算资源
    • 存储管理
      • GlusterFS
        • 使用 GlusterFS 做持久化存储
        • 使用 Heketi 作为 Kubernetes 的持久存储 GlusterFS 的 external provisioner
        • 在 OpenShift 中使用 GlusterFS 做持久化存储
      • GlusterD-2.0
      • Ceph
        • 用 Helm 托管安装 Ceph 集群并提供后端存储
        • 使用 Ceph 做持久化存储
        • 使用 rbd-provisioner 提供 rbd 持久化存储
      • OpenEBS
        • 使用 OpenEBS 做持久化存储
      • Rook
      • NFS
        • 利用 NFS 动态提供 Kubernetes 后端存储卷
    • 集群与应用监控
      • Heapster
        • 使用 Heapster 获取集群和对象的 metric 数据
      • Prometheus
        • 使用 Prometheus 监控 Kubernetes 集群
        • Prometheus 查询语言 PromQL 使用说明
      • 使用 Vistio 监控 Istio 服务网格中的流量
    • 分布式追踪
      • OpenTracing
    • 服务编排管理
      • 使用 Helm 管理 Kubernetes 应用
      • 构建私有 Chart 仓库
    • 持续集成与发布
      • 使用 Jenkins 进行持续集成与发布
      • 使用 Drone 进行持续集成与发布
    • 更新与升级
      • 手动升级 Kubernetes 集群
      • 升级 dashboard
    • 扩展控制器
      • OpenKruise
        • 原地升级
    • 安全策略
      • 开放策略代理(OPA)
      • 云原生安全
  • 服务网格
    • 服务网格(Service Mesh)
    • 企业级服务网格架构
      • 服务网格基础
      • 服务网格技术对比
      • 服务网格对比 API 网关
      • 采纳和演进
      • 定制和集成
      • 总结
    • Istio
      • 使用 Istio 前需要考虑的问题
      • Istio 中 sidecar 的注入规范及示例
      • 如何参与 Istio 社区及注意事项
      • Istio 免费学习资源汇总
      • Sidecar 的注入与流量劫持
      • Envoy Sidecar 代理的路由转发
      • Istio 如何支持虚拟机
      • Istio 支持虚拟机的历史
    • Envoy
      • Envoy 的架构与基本术语
      • Envoy 作为前端代理
      • Envoy mesh 教程
  • 领域应用
    • 领域应用概览
    • 微服务架构
      • 微服务中的服务发现
      • 使用 Java 构建微服务并发布到 Kubernetes 平台
        • Spring Boot 快速开始指南
    • 大数据
      • Spark 与 Kubernetes
        • Spark standalone on Kubernetes
        • 运行支持 Kubernetes 原生调度的 Spark 程序
    • Serverless 架构
      • 理解 Serverless
      • FaaS(函数即服务)
        • OpenFaaS 快速入门指南
      • Knative
    • 边缘计算
    • 人工智能
    • 可观察性
  • 开发指南
    • 开发指南概览
    • SIG 和工作组
    • 开发环境搭建
      • 本地分布式开发环境搭建(使用 Vagrant 和 Virtualbox)
    • 单元测试和集成测试
    • client-go 示例
      • client-go 中的 informer 源码分析
    • Operator
      • operator-sdk
    • kubebuilder
      • 使用 kubebuilder 创建 operator 示例
    • 高级开发指南
    • 社区贡献
    • Minikube
  • 社区及生态
    • 云原生计算基金会(CNCF)
      • CNCF 章程
      • CNCF 特别兴趣小组(SIG)说明
      • 开源项目加入 CNCF Sandbox 的要求
      • CNCF 中的项目治理
      • CNCF Ambassador
    • 认证及培训
      • 认证 Kubernetes 服务提供商(KCSP)说明
      • 认证 Kubernetes 管理员(CKA)说明
  • 附录
    • 附录说明
    • Kubernetes 中的应用故障排查
    • Kubernetes 相关资讯和情报链接
    • Docker 最佳实践
    • Kubernetes 使用技巧
    • Kubernetes 相关问题记录
    • Kubernetes 及云原生年度总结及展望
      • Kubernetes 与云原生 2017 年年终总结及 2018 年展望
      • Kubernetes 与云原生 2018 年年终总结及 2019 年展望
    • CNCF 年度报告解读
      • CNCF 2018 年年度报告解读
      • CNCF 2020 年年度报告解读
由 GitBook 提供支持
在本页
  • 容器
  • 为什么使用 Kubernetes
  • 微服务
  • 云原生
  • 服务网格
  • 使用场景
  • 开源
  • 更多
  1. 云原生

云原生应用之路 —— 从 Kubernetes 到云原生

上一页Kubernetes 与云原生应用概览下一页定义云原生应用

最后更新于3年前

注:本文根据笔者在 和 中分享的话题《从 Kubernetes 到云原生—— 云原生应用之路》改写而成。

本文简要介绍了容器技术发展的路径,为何 Kubernetes 的出现是容器技术发展到这一步的必然选择,而为何 Kubernetes 又将成为云原生应用的基石。

我的分享按照这样的主线展开:容器 -> Kubernetes -> 微服务 ->云原生 -> 服务网格 -> 使用场景 -> 开源。

容器

容器 ——云原生的基石

容器最初是通过开发者工具而流行,可以使用它来做隔离的开发测试环境和持续集成环境,这些都是因为容器轻量级,易于配置和使用带来的优势,docker 和 docker-compose 这样的工具极大的方便的了应用开发环境的搭建,开发者就像是化学家一样在其中小心翼翼的进行各种调试和开发。

随着容器的在开发者中的普及,已经大家对 CI 流程的熟悉,容器周边的各种工具蓬勃发展,俨然形成了一个小生态,在 2016 年达到顶峰,下面这张是我画的容器生态图。

该生态涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面,随着在单主机中运行容器的成熟,集群管理和容器编排成为容器技术亟待解决的问题。譬如化学家在实验室中研究出来的新产品,如何推向市场,进行大规模生产,成了新的议题。

为什么使用 Kubernetes

Kubernetes—— 让容器应用进入大规模工业生产。

Kubernetes 是容器编排系统的事实标准

在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos 和 Kubernetes 的大战已经基本宣告结束,Kubernetes 成为了无可争议的赢家。

下面这张图是 Kubernetes 的架构图(图片来自网络),其中显示了组件之间交互的接口 CNI、CRI、OCI 等,这些将 Kubernetes 与某款具体产品解耦,给用户最大的定制程度,使得 Kubernetes 有机会成为跨云的真正的云原生应用的操作系统。

随着 Kubernetes 的日趋成熟,“Kubernetes is becoming boring”,基于该 “操作系统” 之上构建的适用于不同场景的应用将成为新的发展方向,就像我们将石油开采出来后,提炼出汽油、柴油、沥青等等,所有的材料都将找到自己的用途,Kubernetes 也是,毕竟我们谁也不是为了部署和管理容器而用 Kubernetes,承载其上的应用才是价值之所在。

云原生的核心目标

云已经可以为我们提供稳定可以唾手可得的基础设施,但是业务上云成了一个难题,Kubernetes 的出现与其说是从最初的容器编排解决方案,倒不如说是为了解决应用上云(即云原生应用)这个难题。

包括微服务和 FaaS/Serverless 架构,都可以作为云原生应用的架构。

另外基于 Kubernetes 的构建 PaaS 平台和 Serverless 也处于爆发的准备的阶段,如下图中 Gartner 的报告中所示:

2017 年时各大公有云如 Google GKE、微软 Azure ACS、亚马逊 EKS(2018 年上线)、VMware、Pivotal(后被VMware 收购)、腾讯云、阿里云等都提供了 Kubernetes 服务。

微服务

微服务——Cloud Native 的应用架构。

微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。

就拿微服务中最基础的服务注册发现功能来说,其方式分为客户端服务发现和服务端服务发现两种,Java 应用中常用的方式是使用 Eureka 和 Ribbon 做服务注册发现和负载均衡,这属于客户端服务发现,而在 Kubernetes 中则可以使用 DNS、Service 和 Ingress 来实现,不需要修改应用代码,直接从网络层面来实现。

云原生

DevOps——通向云原生的云梯

CNCF(云原生计算基金会)给出了云原生应用的三大特征:

  • 容器化包装:软件应用的进程应该包装在容器中独立运行。

  • 动态管理:通过集中式的编排调度系统来动态的管理和调度。

  • 微服务化:明确服务间的依赖,互相解耦。

下图是我整理的关于云原生所需要的能力和特征。

使用 Kubernetes 构建云原生应用

  1. 基准代码

  2. 依赖管理

  3. 配置

  4. 后端服务

  5. 构建,发布,运行

  6. 无状态进程

  7. 端口绑定

  8. 并发

  9. 易处理

  10. 开发环境与线上环境等价

  11. 日志作为事件流

  12. 管理进程

另外还有补充的三点:

  • API声明管理

  • 认证和授权

  • 监控与告警

如果落实的具体的工具,请看下图,使用Kubernetes构建云原生架构:

结合这 12 因素对开发或者改造后的应用适合部署到 Kubernetes 之上,基本流程如下图所示:

迁移到云架构

服务网格

Services for show, meshes for a pro.

Kubernetes 中的应用将作为微服务运行,但是 Kubernetes 本身并没有给出微服务治理的解决方案,比如服务的限流、熔断、良好的灰度发布支持等。

Service Mesh 可以用来做什么

  • Traffic Management:API 网关

  • Observability:服务调用和性能分析

  • Policy Enforcment:控制服务访问策略

  • Service Identity and Security:安全保护

Service Mesh 的特点

  • 专用的基础设施层

  • 轻量级高性能网络代理

  • 提供安全的、快速的、可靠地服务间通讯

  • 扩展 kubernetes 的应用负载均衡机制,实现灰度发布

  • 完全解耦于应用,应用可以无感知,加速应用的微服务和云原生转型

使用 Service Mesh 将可以有效的治理 Kubernetes 中运行的服务,当前开源的流行的 Service Mesh 有:

Istio VS Linkerd

Linkerd 和 Istio 是最早开源的 Service Mesh,它们都支持 Kubernetes,下面是它们之间的一些特性对比。

Feature

Istio

Linkerd

部署架构

Envoy/Sidecar

DaemonSets

易用性

复杂

简单

支持平台

Kubernetes

Kubernetes/Mesos/Istio/Local

是否已有生产部署

是

是

关于两者的架构可以参考各自的官方文档,我只从其在Kubernetes上的部署结构来说明其区别。

Istio 的组件复杂,可以分别部署在 Kubernetes 集群中,但是作为核心路由组件 Envoy 是以 Sidecar 形式与应用运行在同一个 Pod 中的,所有进入该 Pod 中的流量都需要先经过 Envoy。

使用场景

云原生的大规模工业生产

GitOps

给开发者带来最大的配置和上线的灵活性,践行 DevOps 流程,改善研发效率,下图这样的情况将更少发生。

我们知道 Kubernetes 中的所有应用的部署都是基于YAML文件的,这实际上就是一种 Infrastructure as code,完全可以通过 Git 来管控基础设施和部署环境的变更。

大数据

Spark 现在已经非官方支持了基于 Kubernetes 的原生调度,其具有以下特点:

  • Kubernetes 原生调度:与 yarn、mesos 同级

  • 资源隔离,粒度更细:以 namespace 来划分用户

  • 监控的变革:单次任务资源计量

  • 日志的变革:pod 的日志收集

特性

Yarn

Kubernetes

队列

queue

namespace

实例

ExcutorContainer

Executor Pod

网络

host

plugin

异构

no

yes

安全

RBAC

ACL

下图是在 Kubernetes 上运行三种调度方式的 spark 的单个节点的应用部分对比:

从上图中可以看到在 Kubernetes 上使用 YARN 调度、standalone 调度和 Kubernetes 原生调度的方式,每个 node 节点上的 Pod 内的 Spark Executor 分布,毫无疑问,使用 Kubernetes 原生调度的 Spark 任务才是最节省资源的。

提交任务的语句看起来会像是这样的:

./spark-submit \
  --deploy-mode cluster \
  --class com.talkingdata.alluxio.hadooptest \
  --master k8s://https://172.20.0.113:6443 \
  --kubernetes-namespace spark-cluster \
  --conf spark.kubernetes.driverEnv.SPARK_USER=hadoop \
  --conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop \
  --conf spark.executorEnv.HADOOP_USER_NAME=hadoop \
  --conf spark.executorEnv.SPARK_USER=hadoop \
  --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
  --conf spark.driver.memory=100G \
  --conf spark.executor.memory=10G \
  --conf spark.driver.cores=30 \
  --conf spark.executor.cores=2 \
  --conf spark.driver.maxResultSize=10240m \
  --conf spark.kubernetes.driver.limit.cores=32 \
  --conf spark.kubernetes.executor.limit.cores=3 \
  --conf spark.kubernetes.executor.memoryOverhead=2g \
  --conf spark.executor.instances=5 \
  --conf spark.app.name=spark-pi \
  --conf spark.kubernetes.driver.docker.image=spark-driver:v2.1.0-kubernetes-0.3.1-1 \
  --conf spark.kubernetes.executor.docker.image=spark-executor:v2.1.0-kubernetes-0.3.1-1 \
  --conf spark.kubernetes.initcontainer.docker.image=spark-init:v2.1.0-kubernetes-0.3.1-1 \
  --conf spark.kubernetes.resourceStagingServer.uri=http://172.20.0.114:31000 \
~/Downloads/tendcloud_2.10-1.0.jar

开源

Contributing is Not only about code, it is about helping a community.

下图是我们刚调研准备使用 Kubernetes 时候的调研方案选择。

对于一个初次接触 Kubernetes 的人来说,看到这样一个庞大的架构选型时会望而生畏,但是 Kubernetes 的开源社区帮助了我们很多。

更多

但就 2017 年为止,Kubernetes 的主要使用场景也主要作为应用开发测试环境、CI/CD 和运行 Web 应用这几个领域,如下图 的 Kubernetes 生态状况调查报告所示。

下图是 给出的微服务中应该关心的主题,图片来自 。

当前最成熟最完整的微服务框架可以说非 莫属,而 Spring 又仅限于 Java 语言开发,其架构本身又跟 Kubernetes 存在很多重合的部分,如何探索将 Kubernetes 作为微服务架构平台就成为一个热点话题。

Cloud Native Features

所托管的应用(即正式捐献给 CNCF 的应用,2017 年已达 12 个),即朝着这个目标发展,其公布的 ,给出了云原生生态的参考体系。

我们都是知道 Heroku 推出了适用于 PaaS 的 的规范,包括如下要素:

迁移到云端架构,相对单体架构来说会带来很多挑战。比如自动的持续集成与发布、服务监控的变革、服务暴露、权限的管控等。这些具体细节请参考 中的说明,在此就不细节展开,另外推荐一本我翻译的由 Pivotal 出品的电子书——,推荐大家阅读。

:由最早提出 Service Mesh 的公司 开源,创始人来自 Twitter

:由 Lyft 开源,可以在 Istio 中使用 Sidecar 模式运行以作为数据平面,也可以基于它来构建自己的服务网格

:由 Google、IBM、Lyft 联合开发并开源

此外还有很多其它的 Service Mesh 鱼贯而出,请参考 。

Linker 的部署十分简单,本身就是一个镜像,使用 Kubernetes 的 方式在每个 node 节点上运行。

关于支持 Kubernetes 原生调度的 Spark 请参考 。

Bilgin Ibryam 写了这篇《》,可以帮助大家更好的理解基于 Kubernetes 的分布式系统的演进。

TheNewStack
Bilgin Ibryam
RedHat Developers
Spring
CNCF
Cloud Native Landscape
12 因素应用
Kubernetes Handbook
《迁移到云原生应用架构》
Linkerd
Buoyant
Envoy
Istio
awesome-cloud-native
DaemonSet
spark-on-k8s
分布式系统在 Kubernetes 上的进化
ArchSummit 2017 北京站
数人云 & TalkingData 合办的 Service Mesh is coming meetup
容器生态图
Kubernetes架构
云原生的核心目标
FaaS Landscape
运行在 Kubernetes 上的负载(2017 年)
Gartner 技术爆发趋势图(2017 年)
微服务的关注点
微服务中的两种服务发现方式
Cloud Native Landscape v1.0
使用 Kubernetes 构建云原生架构应用
创建 Kubernetes 原生应用
istio vs linkerd
部署流水线
使用不同调度器的 Spark on Kubernetes
Kubernetes 解决方案
Kubernetes SIG