kubernetes与云原生
1. 云原生基石之一容器技术
在开发部署应用的过程当中总会出现测试环境明明好好的，部署获得正式环境就会出现各类各样的莫名其妙的问题，尤为是一些部署复杂的应用。有时会遇到须要部署多个相同的应用，又不得不投入大量人力、时间等资源消耗在这种重复性工做上。当面对部署数量高达千甚至万级别的应用的时候，问题更加突出，大量资源被这些运维成本吞噬。
因而工程师们在想能不能把应用程序所须要的环境（环境变量，hosts，数据存储位置等）所有包含到应用中。造成一种自包含的自给自足的小生态体系。部署只需运行这个总体而无需再配置（或者少许配置）各类环境变量。
复制虚拟机，运行多个虚拟机，的确能知足需求，可是虚拟机镜像少则几个G（例如ubuntu centos）多则几十个G（windows），过于消耗存储资源，并且虚拟机对资源损耗较大。因而容器技术应运而生。
容器是一种轻量级、可移植、自包含的软件打包技术，它使得应用能够在几乎任何地方以相同方式运行。（盗用别人的描述）
容器技术有不少实现方式，下面介绍容器技术的一种实现docker。linux
1.1 docker
- 首先我提出三个问题
- 什么是docker
- docker与虚拟机区别
- 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下的资源）
- control group
包含如下隔离
Cpu、cpuset
memory
blkio
net_cls,
net_prio,
devices
cgroup是内核提供用来限制进程对cpu，内存等资源的使用。cgroup是一个树形目录结构，造成层级结构。来完成不一样层级的资源限制。（利于限制某进程pid只能使用0.5core ，500M内存等） - aufs层叠文件系统
层叠文件系统实现了镜像叠加复用机制，它把镜像拆分红不少部分，例如多个镜像由ubuntu镜像、上层应用镜像和环境配置组成，那么只需本地存储一份ubuntu镜像，而上层不一样的部分引用下层公共相同部分组成整个镜像。这样节省存储空间，并且将镜像拆分多个部分有利于并行分发等。在下次下载含有ubuntu镜像的镜像时，只用下载上层不一样的部分。（拓展 copy on write 有时间再补）
- 对比虚拟机，docker 虽然有不少优点，但有一些方面存在劣势。docker隔离等级没有虚拟机高。当docker容器内部进程是以宿主的root用户启动时，会存在安全问题，这会致使容器控制宿主机破坏宿主机的风险。docker没有本身的内核，是经过映射到宿主机的系统调用实现相关功能。它不能更改内核，若是有内核依赖的应用，会存在限制。也是由于没有内核因此一些基础设施镜像只用实现运行时相关的库便可，例如alpine镜像只有几兆大小包含几百个linux命令，适合运行一些小任务，及其节省资源。
- Docker的限制
- Docker让应用部署的复杂度下降了，可是以容器运行的应用间的协同却成了新的亟需解决的问题，这种需求在微服务中表现尤其明显。
- 当运行大量的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可重名。
部分来自阿里云云原生技术公开课 https://edu.aliyun.com/roadmap/cloudnative#course
---- 后续有空再补git