容器与云原生入门笔记实践
目录
什么是容器?
容器基本概念
容器关键技术
编辑
容器与虚拟机
容器化优势
容器时代
什么是Docker？
Docker镜像的价值:
容器核心价值
Docker 引擎
Docker 架构
Docker容器实现原理
Namespace
如何使用Dockerfile构建镜像
Dockerfile
什么是Kubernetes？
Master节点
Node节点
容器与云原生
云原生应用的适用场景
云原生应用的12-Factors要素
传统应用与云原生应用的区别对比
云原生架构演进原则
云原生应用架构思考:单体架构的局限性
云原生架构模式: Serverless架构
Serverless与微服务的关系:微服务向Serverless演进，并长期共存
云原生未来发展趋势
Kubernetes编排统一化﹐编排对象不断扩展延伸
服务治理Mesh化，加速传统应用转型
应用服务Serverless化，更加聚焦业务的核心价值
云原生服务部署形态多元化，多云将成为主流
容器部署初体验
关闭防火墙和selinux
Docker安装
什么是容器?
容器为App提供独立的、受控的运行环境，是一种轻量级的操作系统虚拟化。
简单的容器:SandBox(沙盒、沙箱)
- 容器是应用软件高效研发、交付、分发的最佳技术承载，一次构建，到处运行（Build Once,Run Anywhere）。
容器基本概念
- 1、容器
- 2、镜像：让容器运行不再依赖外部环境，方便部署与应用移植
容器关键技术
容器是一种创建隔离环境，方便高效的打包和分发应用的技术创建隔离环境： NameSpace 与Cgroup
打包与分发：容器镜像，镜像仓库
容器与虚拟机
使用虚拟机运行多个相互隔离的应用时，不难发现，相比于虚拟机，Docker要简洁很多。
Docker守护进程可以直接与主操作系统进行通信，为各个Docker容器分配资源；它还可以将容器与主操作系统隔离，并将各个容器互相隔离。虚拟机启动需要数分钟，而Docker容器可以在数毫秒内启动。由于没有臃肿的从操作系统，Docker可以节省大量的磁盘空间以及其他系统资源。
与虚拟机不同，容器持续的时间是短暂的，它们会自动启动和关闭。但是像虚拟机一样，容器需要访问持久性存储，以在生产环境中发挥其全部潜力。如果没有持久性存储，则在容器关闭时数据会“死亡”。基于容器的应用程序的企业级存储基础设施必须提供功能强大的持久存储。但这只是一个开始，为了更好地发展，容器环境需要支持容器具有轻量、移动和短暂特性的存储生态系统。
容器化优势
1、开销更小：系统资源占用较少，启动时间短，镜像存储占用空间较少
2、轻松部署“”可部署较大规模的集群，进行快速编排，帮助用户关注业务本身
3、环境标准化：容器包含应用运行所需的环境依赖，保证了应用运行环境的一致性，避免环境不同带来的问题
4、版本控制：容器镜像可以通过不同的版本进行管理
容器时代
Docker ——以Docker为代表的容器引擎技术
Docker诞生于2013年,设计思想来源于集装箱,将软件的交付向集装箱运输一样标准化，同时各个“集装箱”中的软件独立运行，互不影响;
一经推出便迅速获得了业界的热捧，统-一了纷乱的云计算PaaS的技术，垄断了容器市场;
2015年由Docker主导的容器技术标准组织OCI成立，确立了业界公认的容器引擎技术的标准;
Kubernetes（K8s）——以K8S为标准的容器编排技术
Kubernetes诞生于2014年，是Google根据15年大规模集群管理经验积累结合Docker技术向业界开源的容器编排管理技术;
推出后凭借其开放的开源生态，吸引了Redhat.VMware、华为等业界顶级公司的参与，共同打造成了容器编排技术的事实标准;
.2015年这些业界顶级公司成立了CNCF云原生基金会，成为云计算领域的顶级开源组织
什么是Docker？
最主流的容器运行时技术，提供了容器的运行时能力，经过多次容器技术标准的演进和OCI标准的确立，目前Docker的架构如下如所示:
Docker所应用三个关键技术，实现轻量化的隔离技术: 码头所应用三个关键技术，实现轻量化的隔离技术：
1、Namespace:实现容器运行环境的隔离，容器应用进程之间不可见. Cgroup:实现容器运行的资源隔离，避免容器间资源抢占和冲突 命名空间：实现容器运行环境的隔离，容器应用进程之间不可见。
2、Cgroup：实现容器运行的资源隔离，避免容器间资源抢占和冲突。
3、Union Filesystem:一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来叠加，是容器镜像的基础 。联合文件系统：一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来叠加，是容器镜像的基础。
关键概念
- 镜像：应用发布的标准格式，通过Dockerfile描述，可构建为一个tar包
- 镜像仓库：存放镜像文件的场所。Docker官方镜像仓库:https://hub.docker.com/
- 容器：容器是从镜像创建的运行实例，可以被启动、停止和删除。一个容器镜像可以构建多个容器
Docker镜像的价值:
- Docker镜像提供了一种全新的软件格式，使得软件的分发变得容易
- Build Once，Run Anywhere
- Docker镜像分层的特性，也使得该软件格式能够被速打包，占用空间也大大减少
容器技术–提高应用可移植性，提升业务敏捷
- 容器可以将应用本身及其依赖打包，使得应用可以实现“一次封装，到处运行”。
- 容器也可以理解成一种沙盒技术，沙盒在计算机安全领域中是一种安全机制，为运行中的程序提供的隔离环境。
容器核心价值
- 可移植性:环境标准化，应用随处运行
- 敏捷:创建速度快，秒级资源弹性
- 提高生产力:消除跨服务依赖性和冲突
Docker 引擎
Docker主要指容器引擎,即Docker engine。Docker Engine是-个Client/Server应用程序。Docker engine主要组件有3部分:
服务器:是一个长期运行的程序,称为daemon进程:Docker daemon用于创建和管理docker对象,如容器镜像、容器、网络、卷。
命令行界面客户端(docker CLI):CLI使用Docker REST API通过脚本或直接的CLI命令与Docker daemon交互。
一个REST API:Client可以用它来与daemon进程通信交互。
Docker 架构
Docker Client: Docker是个采用的C/S架构的应用程序。Docker Client一般通过Docker command来发起请求。在用户界面,支持用户与Docker Daemon之间通信
Docker daemon :简单地说, Docker daemon实现的功能就是接收客户端发来的请求,并实现请求所要求的功能,同时针对请求返回相应的结果。Docker daemon是驱动整个Docker功能的核心引擎。在功能的实现上,Docker daemon涉及了容器、镜像、存储等多方面的内容,涉及多个模块的实现和交互。
Containers :容器以镜像为基础,同时又为镜像提供了一个标准和隔离的运行环境。Docker的容器就是“软件界的集装箱”,可以安装任意的软件和库文件,做任意的运行环境配置。开发及运维人员在转移和部署应用的时候,不需关心容器里装了什么软件,也不需了解它们是如何配置的。
Docker Image :与容器相对应,如果说容器提供了一个完整的、隔离的运行环境,那么镜像则是这个运行环境的静态体现
Registry : Registry是一个存放镜像的仓库。Registry本身也是一个单独的开源项目企业可使用Registry镜像搭建私有仓库。
Docker容器实现原理
Docker容器通过namespace技术实现进程隔离,通过cgroup技术实现容器进程可用资源的限制。Docker启动一个容器时,实际是创建了包含多个namespace参数的进程。
Namespace
Namespace :命名空间作用:资源隔离。 namespace将内核的全局资源进行封装,使得每个namespace都有一份独立的资源。因此不同进程在各自namespace内对同一种资源的使用不会相互干扰。
Namespace实际上是Linux系统上创建新进程时的一个可选参数。实际上在创建Docker容器时,指定了这个进程所需要启用的一组namespace参数。通过namespace机制的隔离,容器只能见到当前Namespace中所限定的资源、文件、设备、状态或配置。以此实现应用运行环境的隔离。
如何使用Dockerfile构建镜像
Dockerfile是一个文本文件,其内包含了一条条的指令,每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。所以为了减少存储占用，一般尽可能把run指令写到一行。
Docker提供了两种构建镜像的方法：docker commit命令与dockerfile构建文件。
Dockerfile
Dockerfile :文件指令集,描述如何自动创建Docker镜像。
Dockerfile是包含若干指令的文本文件,可以通过这些指令创建出docker image。
Dockerfile文件中的指令执行后,会创建一个个新的镜像层。
Dockerfile文件中的注释以"#"开始。
Dockerfile一般由4部分组成:
- 基础镜像信息.
- 维护者信息
- 镜像操作指令
- 容器启动指令
build context :为镜像构建提供所需的文件或目录。
什么是Kubernetes？
Kubernetes是Google开源的容器集群管理系统;它构建在Docker技术之上，为容器化的应用提供资源调度，部署运行，服务发现，扩容缩容等一整套功能，本质上是基于容器技术的Micro-PaaS平台，Kubernetes的灵感来源于Google内部的Borg系统
将Docker容器宿主机组成集群，统一进行资源调度，自动管理容器生命周期，提供跨节点服务发现和负载均衡;更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入
Kubernetes是CNCF社区最核心的开源项目，为容器化的应用提供资源调度，部署运行，服务发现，扩容缩容等一整套功能，是容器技术事实上的行业标准
Kubernetes的技术特点:
- 通过声明性语法直接定义应用的最终状态
- 提供开放的开放的插件机制
- 灵活的资源权限隔离机制
Kubernetes的技术优势:
- 由定义的应用状态，自动的部署、重启、迁移、伸缩
- 插件机制使K8S兼容各类基础设施（公有云、私有云)
- 灵活的隔离机制能够快速为不同团队构建运行环境
K8s集群主要包括两个部分:Master节点（管理节点)和Node节点(计算节点)
Master节点主要还是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。
Master节点
Master节点提供的集群控制，对集群做出全局性决策，例如调度等。通常在master节点上不运行用户容器。
Master节点包括API Server、Scheduler、Controller manager、etcd。
API Server :整个系统的对外接口
Scheduler:集群内部的资源进行调度
Controller Manager:负责管理控制器
etcd : Kubernetes的后端存储
Node节点
节点组件运行在每一个Node节点上，维护运行的pod并提供kubernetes运行时环境。
Node节点包括Pod、Docker、kubelet、kube-proxy、Fluentd、kube-dns (可选
Pod是K8s最小单位
Pod : Kubernetes最基本的操作单元
Docker :创建容器;
Kubelet:负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等;
Kube-proxy∶负责为Pod对象提供代理
Fluentd:主要负责日志收集、存储与查询。
容器与云原生
移动互联网时代，对软件开发形成巨大推动力 软件上云，大势所趋
企业IT——规模小,变化慢
电信——规模大，变化相对慢，应对硬件失败
初创公司——规模小，变化快，应对软件失败
网络规模化企业——规模大，变化快，软硬件都会有问题
基于云原生的相关技术，设计运行在云上的，充分发挥云优势的应用。
一般采用容器的打包、分发、部署的形式，应用内(间）采用微服务的架构，充分利用云提供的组件服务，采用DevOps的组织架构和方法，通过CI/CD工具链，实现产品和服务的持续交付。
云原生应用的适用场景
需要以极快的速度迭代交付IT产品或服务，来满足客户需求的组织，例如:
- 互联网企业
- ISV提供商
- 智能设备提供商
- 云服务商
- 信息服务提供商
云原生应用的12-Factors要素
Heroku于2012年提出12因素，告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。
12-Factor为构建如下的SaaS应用提供了方法论:
- 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目
- 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性
- 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源
- 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发
- 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展
这套理论适用任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。
价值及实现方法
- 快速交付：合理划分边界;良好的软件生命周期管理
- 提升开发效率：标准化，排除意外风险
- 软件发布管理：通过流水线实现CI/CD自动化
- 软件发布管理;将配置转为环境变量
- 实时系统指标：日志管理系统
- 自动弹性伸缩：将缓慢的进程转变为后端服务
- 弹性/敏捷：使用断路器;松散绑定
- 可靠性：凭借云平台营个
- 可靠性：转变为后端服务,并暴露为REST接口
- 运营效率：应用服务只需要知道URL地址与对应端口
- 云兼容性：将状态管理交给后端服务
- 自动弹性伸缩：转为云平台设计,使用PaaS的功能
传统应用与云原生应用的区别对比
| 云原生应用 | 传统应用 |
| 可预测。云原生应用符合旨在通过可预测行为最大限度提高弹性的框架或“合同” | 不可预测。通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障 |
| 操作系统抽象化 | 依赖操作系统 |
| 资源调度有弹性 | 资源冗余较多，缺乏扩展能力 |
| 团队借助DevOps更容易达成协作 | 部门墙导致团队彼此孤立 |
| 敏捷开发 | 瀑布式开发 |
| 微服务各自独立，高内聚，低耦合 | 单体服务耦合严重 |
| 自动化运维能力 | 手动运维 |
| 快速恢复 | 恢复缓慢 |
云原生架构演进原则
- 弹性：微服务采用无状态设计,支持按需使用、自动水平伸缩;实例快速启动，并在不影响业务的前提下优雅中止。
- 分布式：应用分布式:业务逻辑与数据解耦、业务逻辑与会话解耦；数据分布式:去中心、自均衡、最终一致性;跨可用区的部署与调度。
- 高可用：基于不可靠、可抛弃的资源设计高可用、反脆弱系统,应用任意(微)服务实例失效，系统能够快速发现、隔离并自动恢复；云基础设施和平台服务发生任意单点故障不影响系统整体可用性。
- 自动化：系统能够自动化部署、升级和扩缩容,支持自动化监控、告警、故障的定界定位和故障自愈。
- 自服务：服务可被其他应用或开发者自助发现，自助按需获取，自助使用并计量，自助服务管理。
云原生应用架构思考:单体架构的局限性
单体架构的问题不在于不可拆分上，在于无法隔离和自治。应用规模越大，局限性越明显
- 大规模团队——组建大规模软件团队,成员之间需要精确协作才能正确开发、测试和部署应用，沟通和协难度大;
- 重复造轮子——每个单体架构的业务应用重复开发业务组件,效率低下;
- 上线周期长——更新一个新功能需要进行整体测试和部署，上线周期数天~数周;
- 粗粒度扩容——资源不够时进行整体粗粒度资源扩容(物理机/虚拟机)，资源消耗大
云原生架构模式: Serverless架构
Serverless（无服务器架构）指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理，Serverless是在传统容器技术和服务网格上发展起来，更侧重让使用者只关注自己的业务逻辑即可。
Serverless方案业务价值
- 更轻量化：用户专注于业务创新和代码开发，代码运行环境由云平台提供，无需管理基础设施资源。
- 更快弹性：根据请求的并发数量自动调度资源运行函数，毫秒级弹性伸缩，高效应对业务峰值。
- 更低成本：根据函数调用次数、运行时长和节点转换次数计费，函数不运行时不产生费用，更加节省成本。
Serverless与微服务的关系:微服务向Serverless演进，并长期共存
- 主要变化:
- 更快的弹性
- 更快的发布更简化的运维
- 更细粒度的资源调度事件驱动的架构
云原生未来发展趋势
Kubernetes编排统一化﹐编排对象不断扩展延伸
调查数据显示﹐Kubernetes在受访人群的采纳率高达63%,在容器编排领域扮演非常重要的角色。
Kubernetes的编排对象持扩展
以容器为基础编排对象逐渐延展至虚拟机﹑函数等﹐理论上所有可编程﹑有API·可抽象成资源的对象﹐都在成为Kubernetes 的编排对象。
应用侧围绕Kubernetes生态加速演进
以Kubernetes为核心的云原生技术栈将推广到更多的应用场景。在大数据领域﹐Spark和Kubernetes的集成已经非常普遍﹔机器学习方面﹐用Kubernetes去编排机器学习的工作流以取得业界的广泛共识·
服务治理Mesh化，加速传统应用转型
根据CNCF调查数据，38%的单位在生产中使用服务网格，42%的调查对象在评估服务网格，11%计划在未来12个月使用，因此预计在未来年份中，服务网格会成为一个增长领城
lstio、Consul、Linkerd是Service Mesh领域最受欢迎的三大解决方案。
Mesh化是传统应用转型云原生的关键路径
1、服务治理与业务逻辑解耦
将服务通信及相关管控功能从业务程序中分离并下层到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身。
2、异构系统的统一治理
通过服务网格技术将主体的服务治理能力下沉到基础设施，可方便地实现多语言、多协议的统一流量管控、监控等需求。
应用服务Serverless化，更加聚焦业务的核心价值
Serverless作为下一代云计算范式，基于Serverless的应用生命周期将出现重大的改变，整个过程无须关注底层服务器资源的调度，并且应用天生具备高可用高弹性。
作为云原生技术未来的演进方向，无服务器架构技术serverless开始从观望逐渐落地。
Serverless将进一步释放云计算的能力，使用户聚焦核心业务逻辑，极大提升应用开发效率。
云原生服务部署形态多元化，多云将成为主流
尽管上云已是大势所趋，但对于企业客户而言，有些业务出于对数据主权、安全隐私的考量，会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性等需求，会选择多个云厂商。
《2020年中国云原生用户调查报告》显示，74%的用户已经在使用或未来1年计划采用多云/混合云架构。
随着云原生技术和云市场不断成熟，多云、多集群部署渐成为常态，未来将是编程式多云管理服务的时代。
容器部署初体验
实践基于一台2vCPUs | 4GiB |CentOS 7.6 64bit with ARM鲲鹏920服务器
关闭防火墙和selinux
（1）各个节点都执行命令关闭防火墙：
systemctl stop firewalld
systemctl disable firewalld
systemctl status firewalld
（2）关闭selinux
进入selinux的config文件，将selinux原来的强制模式（enforcing）修改为关闭模式（disabled）
setenforce 0getenforce
sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/sysconfig/selinux
grep SELINUX=disabled /etc/sysconfig/selinux
cat /etc/sysconfig/selinux
Docker安装
wget -O /etc/yum.repos.d/docker-ce.repo https://repo.huaweicloud.com/docker-ce/linux/centos/docker-ce.repo
#软件仓库地址替换为：
sudo sed -i 's+download.docker.com+repo.huaweicloud.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo
#更新索引文件并安装
sudo yum makecache fast
sudo yum install docker-ce -y
#启动服务
sudo systemctl start docker
systemctl daemon-reload; systemctl restart docker; systemctl enable docker
systemctl status docker
验证docker安装结果
docker run hello-worldDocker从DockerHub上拉取了hello-world镜像：
查看本机所有容器的Docker服务并换源
# 配置docker
mkdir -p /etc/docker
tee /etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors": ["http://f1361db2.m.daocloud.io"],
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "3"
}
}
EOF
systemctl daemon-reload
systemctl restart docker
#查看镜像
docker ps -a
安装与配置 K8s
启用NET.BRIDGE.BRIDGE-NF-CALL-IPTABLES内核选项：
sysctl -w net.bridge.bridge-nf-call-iptables=1禁用交换分区
swapoff -a
cp -p /etc/fstab /etc/fstab.bak$(date '+%Y%m%d%H%M%S')
sed -i "s/\/dev\/mapper\/centos-swap/\#\/dev\/mapper\/centos-swap/g" /etc/fstab安装K8s组件并验证安装结果
yum install -y kubelet kubeadm kubectl kubernetes-cni
rpm -qa | grep kubelet; rpm -qa | grep kubeadm; rpm -qa | grep kubectl; rpm -qa | grep kubernetes-cni
#设置iptables
echo "net.bridge.bridge-nf-call-iptables=1" > /etc/sysctl.d/k8s.conf
systemctl enable kubelet