kubernetes与云原生

文章目录

1. 云原生基石之一容器技术

在开发部署应用的过程中总会出现测试环境明明好好的，部署得到正式环境就会出现各种各样的莫名其妙的问题，尤其是一些部署复杂的应用。有时会遇到需要部署多个相同的应用，又不得不投入大量人力、时间等资源消耗在这种重复性工作上。当面对部署数量高达千甚至万级别的应用的时候，问题更加突出，大量资源被这些运维成本吞噬。

于是工程师们在想能不能把应用程序所需要的环境（环境变量，hosts，数据存储位置等）全部包含到应用中。形成一种自包含的自给自足的小生态体系。部署只需运行这个整体而无需再配置（或者少量配置）各种环境变量。

复制虚拟机，运行多个虚拟机，的确能满足需求，但是虚拟机镜像少则几个G（例如ubuntu centos）多则几十个G（windows），过于消耗存储资源，而且虚拟机对资源损耗较大。于是容器技术应运而生。

容器是一种轻量级、可移植、自包含的软件打包技术，它使得应用可以在几乎任何地方以相同方式运行。（盗用别人的描述）

容器技术有很多实现方式，下面介绍容器技术的一种实现docker。

1.1 docker

• 首先我提出三个问题

1. 什么是docker

2. docker与虚拟机区别

3. docker如何解决哪些问题

   

   下面分别讲述这些问题：

   • Docker是一个新的容器化开源项目，诞生于 2013 年初，最初是 dotCloud 公司内部的一个业余项目，项目后来加入了 Linux 基金会，遵从了 Apache 2.0 协议，基于 Google 公司推出的 Go 语言实现。

   • Docker 提供了一个可以运行你的应用程序的容器,它可以将应用以及依赖包到一个可移植的容器中,然后发布到任何 Linux机器上。

   • Docker 扩展了 Linux 容器（Linux Containers）通过一个高层次的 API 为进程单独提供了一个轻量级的虚拟环境，有点类似虚拟机的概念

   • Docker包含三个重要组件：镜像，容器，仓库。

     镜像通俗理解就是类似虚拟机里面安装好了应用，并设置了应用开机自启动。

     容器类似运行态的虚拟机和应用组合。

     仓库类似github 存放镜像的仓库。

     

     

     在构造自包含的应用是为什么选取容器而不选用虚拟机上图应该很显而易见了，下面讲解为什么docker资源消耗较少。

• docker 几大核心技术：

  1.命名空间 namespace

  隔离系统资源，在linux内核的6种命名空间类型

  pid namespace

  mnt namespace

  net namespace

  uts namespace

  ipc namespace

  user namespace

  利用linux内核namespace技术实现pid，mnt等视图上的隔离（这些是真实的存在在操作系统上的只是视图上隔离后看不到其他namespace下的资源）

2. control group

   包含以下隔离

   Cpu、cpuset

   memory

   blkio

   net_cls,

   net_prio,

   devices

   cgroup是内核提供用来限制进程对cpu，内存等资源的使用。cgroup是一个树形目录结构，形成层级结构。来完成不同层级的资源限制。（利于限制某进程pid只能使用0.5core ，500M内存等）

3. aufs层叠文件系统

   

   层叠文件系统实现了镜像叠加复用机制，它把镜像拆分成很多部分，例如多个镜像由ubuntu镜像、上层应用镜像和环境配置组成，那么只需本地存储一份ubuntu镜像，而上层不同的部分引用下层公共相同部分组成整个镜像。这样节省存储空间，而且将镜像拆分多个部分有利于并行分发等。在下次下载含有ubuntu镜像的镜像时，只用下载上层不同的部分。（拓展 copy on write 有时间再补）

   

• 对比虚拟机，docker 虽然有很多优势，但有一些方面存在劣势。docker隔离等级没有虚拟机高。当docker容器内部进程是以宿主的root用户启动时，会存在安全问题，这会导致容器控制宿主机破坏宿主机的风险。docker没有自己的内核，是通过映射到宿主机的系统调用实现相关功能。它不能更改内核，如果有内核依赖的应用，会存在限制。也是因为没有内核所以一些基础设施镜像只用实现运行时相关的库即可，例如alpine镜像只有几兆大小包含几百个linux命令，适合运行一些小任务，及其节省资源。
• Docker的限制

1. Docker让应用部署的复杂度降低了，但是以容器运行的应用间的协同却成了新的亟需解决的问题，这种需求在微服务中表现尤为明显。
2. 当运行大量的docker容器时候，这些容器的的管理和编排会越来越困难，用户不得不对容器实施分组，以便跨所有容器提供网络，安全 ，监控等服务。

2. 云原生核心–kubernetes

• docker只是解决服务下层的问题，服务上层建筑如容器编排，服务发现等问题已经超越了docker的管辖。kubernetes应运而生了。

• Kubernetes提供的编排和管理功能，轻松完成大规模容器部署，借助k8s的编排功能，用户可以构建跨多个容器的应用服务，实现跨集群调度，扩展容器，以及长期持续管理这些容器的健康状况等，并整合网络，存储，安全性，监控及其他服务，提供全面的容器基础架构

• 云原生理念：最大化利用云的能力，发挥云的价值的最佳路径

  

• 2013年，docker项目发布

  使得全操作系统语义的沙盒技术唾手可得，对传统的PaaS产业“降维打击”

• 2014年，Kubernetes项目发布

  Google Borg/Omega 系统思想借助开源社区“重生”，“容器设计模式”的思想正式确立

• 2015~2016年，容器编排“三国争霸”

  Docker Swarm, Mesos,Kubernetes 在容器编排领域展开角逐

• 2017年，Kubernetes项目事实标准确立

  Docker 公司宣布在核心产品内置Kubernetes服务，Swarm项目逐渐停止维护

• 2018年，云原生理念逐渐萌芽

  Kubernetes和容器成为所有云厂商上的既定标准，以“云”为核心的软件研发思想逐渐形成

2.1 kubernetes核心概念

• k8s体系结构

  

• 核心概念包含Pod、Volume、Deployment、Service、Namespaces

  pod是k8s最小调度以及资源单元，由一个或者多个容器组成。pod定义容器运行方式（Command、环境变量等），提供容器共享的运行环境（网络、进程空间）

  volume声明在pod中容器可访问的文件目录，目录被挂载在pod中的一个或者多个容器的指定路径下，支持多种后端存储抽象（本地存储，分布式存储，云存储）

  deployment定义一组pod的副本数量、版本等，通过控制器（controller）维持pod的数量。通过控制器以指定策略控制版本（滚动升级、重新生成、回滚等）

  service提供访问一个或者多个pod实例的稳定访问地址。支持多种访问方式实现（ClusterIP、NodePort、Load Balancer）

  Namespaces是集群内部的逻辑隔离机制（鉴权、资源额度），每个资源属于一个namespace，同一个namespace中资源命名唯一，不同namespace可重名。

部分来自阿里云云原生技术公开课

—- 后续有空再补