K8S介绍与特性及K8S前篇

K8S介绍与特性

• Kubernetes概念
  • Kubernets是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。
• K8S概述
  • K8S是谷歌在2014年开源的容器化集群管理系统
  • 使用K8S进行容器化应用部署
  • 使用K8S利于容器扩展
  • K8S目标实施让部署容器化应用更加简洁和高效
• K8S功能：
  • （1）自动装箱
    • 基于容器对应用运行环境的资源配置要求自动部署应用容器
  • （2）自我修复（自愈能力）
    • 当容器失败时，会对容器进行重启
    • 当所部署的Node节点有问题时，会对容器进行重新部署和重新调度
    • 当容器未通过监控检查时，会关闭此容器知道容器正常运行时，才会对外提供服务。
  • （3）水平扩展
    • 通过简单的命令、用户UI界面或基于GPU等资源使用情况，对应用容器机械能规模扩大或规模裁剪
  • （4）服务发现
    • 用户不需要使用额外的服务发现机制，就能够基于Kubernetes自身能力实现服务发现和负载均衡
  • （5）滚动更新
    • 可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新
  • （6）版本回退
    • 可以根据应用的变化，对应用容器运行的应用，进行历史版本即时回退
  • （7）密钥与配置管理
    • 在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署。
  • （8）存储编排
    • 自动实现存储系统挂载及应用，特别对有状态应用实现数据持续化非常重要。存储系统可以来自于本地目录、网络存储（NFS、Gluster、Ceph等）、公共云存储服务
  • （9）批处理
    • 提供一次性任务，定时任务；满足批量数据处理和分析的场景
  •  
• “容器技术”
  • 容器技术这样一个新生事物，完全重塑了整个云计算市场的形态，它不仅催生出了一批年轻有为的容器技术人，更是培育出了一个具有相当规模的开源基础设施市场。
  • 就在这场因“容器”而起的技术变革中，Kubernetes项目已然成为容器技术的事实标准，重新定义了基础设施领域对应用编排与管理的种种可能。
  • 从过去以物理机和虚拟机为主体的开发运维环境，向以容器为核心的基础设施的转变过程，并不是一次温和的改革，而是涵盖了对网络、存储、调度、操作系统、分布式原理等各个方面的容器化理解和改造。
  • 关于Linux内核、分布式系统、网络、存储等方方面面的积累，并不会在Docker或者Kubernetes的文档中交代清楚。可偏偏就是它们，才是真正掌握容器技术体系的精髓所在，是每一位技术从业者需要悉心修炼的“内功”。
  • 从分布式系统设计的视角出发，抽象和归纳出这些特性中体线出来的普遍方法，然后带着这些指导思想逐一阐述Kubernetes项目关于编排、调度和作业管理的各项核心特性。
  • 一个人的命运，当然要靠自我奋斗，但是也要考虑历史的行程。
  • 在沉寂多年的云计算与基础设施领域，一次以“容器”为名的历史变革，正呼之欲出。
• K8S前篇--小鲸鱼大事记
  • Pass项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。
  • 事实上，向Cloud Foundry这样的PaaS项目，最核心的组件就是一套应用的打包和分发机制。关键点：由于需要在一个虚拟机上启动很多个来自不同用户的应用，Cloud Foundry 会调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程。这样，就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。
  • “cf push”虽然能一键部署，但是打包工作繁琐，需要做很多修改和配置才能在PaaS里运行，基本上得靠不断试错。而Docker镜像解决的，恰恰是打包这个根本性得问题。核心点：保证了云端环境和本地环境的高度一致。
  • Docker 项目给 PaaS 世界带来的“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。
  • cloud foundry是标准的pass项目。Kubernetes是容器化基础设施项目。
  • dotClound这个以“鲸鱼”为注册商标的技术创业公司，最重要的战略之一就是：坚持把“开发者”群体放在至高无上的位置。
  •  Docker 项目备受关注的原因
    • 一方面，它解决了应用打包和发布这一困扰运维人员多年的技术难题；
    • 另一方面，就是因为它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里。
  • dotClound公司的想法：如何让开发者把应用部署在我的项目上。
    • Docker 项目从发布之初就全面发力，从技术、社区、商业、市场全方位争取到的开发者群体，实际上是为此后吸引整个生态到自家“PaaS”上的一个铺垫。
    • 只不过这时，“PaaS”的定义已经全然不是 Cloud Foundry 描述的那个样子，而是变成了一套以 Docker 容器为技术核心，以 Docker 镜像为打包标准的、全新的“容器化”思路。
    • 这正是 Docker 项目从一开始悉心运作“容器化”理念和经营整个 Docker 生态的主要目的。
    • 而 Swarm 项目，正是接下来承接 Docker 公司所有这些努力的关键所在。
  • CoreOS和Swarm的不同点：
    • CoreOS是依托于一系列开源项目（比如Container Linux操作系统、Fleet作业调度工具、systemd进程管理和rkt容器），一层层搭建起来的平台产品。
    • Swarm完全使用Docker项目原本的容器管理API来完成集群管理，是以一个完整的整体来对外提供集群管理功能。
  • 编排（Orchestration）:主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。
  • Swarm的另外、一个竞争对手，Mesos拥有一个独特的竞争优势：超大规模集群的管理经验。
  • OCI(Open Container Initiative),意在将容器运行时和镜像的实现从Docker项目完全剥离出来。
  • CFCF的由来：
    • Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。
  • Swarm擅长是跟Docker生态的无缝集成，而Mesos擅长的则是大规模集群的调度与管理。
  • Kubernetes项目的基础特性，并不是几个工程师突然“拍脑袋”想出来的东西，而是Google公司在容器化基础设施这么多年来实践经验的沉淀与升华。
  • 在 2016 年，Docker 公司宣布了一个震惊所有人的计划：放弃现有的 Swarm 项目，将容器编排和集群管理功能全部内置到 Docker 项目当中
    • 实际上，从工程角度来看，这种做法的风险很大。内置容器编排、集群管理和负载均衡能力，固然可以使得Docker项目的边界直接扩大到一个完整的PaaS项目的范畴，但这种变更带来的技术复杂度和维护难度，长远来看对Docker项目是不利的。
  • Kubernetes 的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构
    • 即：从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes 项目的每一个阶段。
  • 基于Kubernetes API和扩展接口创建的好用的项目有：
    • 微服务治理项目Istio;
    • 有状态应用部署框架Operator;
    • Rook,通过Kubernetes的可扩展接口，吧Ceph封装成简单易用的容器存储插件。
  • 以开发者为中心，构建一个相对民主和开放的容器生态。
  •