● 应用构建
○ Java、C++、JavaScript——编程各异
○ 打成软件包
○ .exe（类似Windows，最终也只是生产exe执行）
○ 使用docker build … 打包成 镜像——这就类似于exe

● 应用分享
○ 所有软件的镜像放到一个指定地方 docker hub
○ 类似——安卓，应用市场

● 应用运行
○ 统一标准的 镜像
○ docker run 就好（以前的方法是java -ja…、C++编译再整很多东西等等都不一样）

● …

区别于虚拟化技术：

• 容器化其实是Linux做的，docker对此进行简单封装。docker不带操作系统，既然有了操作系统，只需做一些差异化的工作，所以每一个应用只是差异化环境
  
• 为了隔离应用，使用了虚拟化。但是镜像系统都很大占用。移植起来，需要应用带上整个虚拟机和环境，一起移植到其他设备——非常重量级
  

● cpu、memory资源隔离与限制
● 访问设备隔离与限制
● 网络隔离与限制
● 用户、用户组隔离限制
● …

● Docker_Host：
○ 安装Docker的主机
● Docker Daemon：
○ 运行在Docker主机上的Docker后台进程
● Client：
○ 操作Docker主机的客户端（命令行、UI等）
● Registry：
○ 镜像仓库
○ Docker Hub
● Images：
○ 镜像，带环境打包好的程序，可以直接启动运行
● Containers：
○ 容器，由镜像启动起来正在运行中的程序

交互逻辑：

装好Docker，然后去 软件市场 寻找镜像，下载并运行，查看容器状态日志等排错

• 传统的部署模式中，应用部署在一个操作系统中。如果一个应用内存泄露了，就会把其他应用挤下线，非常不安全
• 虚拟化的部署中，一个应用炸了只能影响到虚拟机内
• 容器化的部署中，在原有的操作系统中有了容器化的运行环境，然后应用就会以容器化的形式运行起来。也能做到资源隔离且轻便

容器化也会带来一个问题：当服务模块众多，每个小项目的微服务都已以容器化的形式部署，并且放到很多台服务器。以前用docker run跑一两个应用，人肉可以运维和操作 ，但是如果几千个容器的话，就难以管理 。因此大规模容器编排系统应运而生（编：同一个应用的容器划分成一组；排：比如A应用在这个服务器不够了，就在别的服务器拿来扩充几个）

kubernetes具有以下特性：
● 服务发现和负载均衡：

• 服务发现：发现宕机有问题的容器，不降任务给他
• 负载均衡：Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

● 存储编排
Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。应用需要内存则找k8s要，k8s开辟一块存储空间。应用删了后存储也没了
● 自动部署和回滚
你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。——回滚到上一次部署的版本
● 自动完成装箱计算
Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。——指定了这么多内存，超过了就会被杀掉
● 自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。——一个机器挂了，可以将其中的容器部署到其他机器
● 密钥与配置管理
Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes Cluster = N Master Node + N Worker Node：N主节点+N工作节点； N>=1

工作起来的核心组件如下图的右侧所示：

为便于理解，以硅谷集团部署飞机项目为例：

1. 一个飞机项目下设的的三个节点即东厂、西厂、南厂 ——node
2. 主节点master为硅谷总部——control plane
3. 决定要干什么的决策者（任何人如厂里的都找不到决策者）——controller manager
4. 整个集团运行的核心数据得用资料库保存——etcd（类似redis的存储库，就像mysql）
5. 负责将数据存进资料库、干杂活则需要秘书干——API server
6. 负责看哪些厂可以做这个项目，需要调度者。但是当调度者决定哪个厂搞了后，需要告诉秘书部，秘书部存档进资料库后再告诉某个厂——Scheduler
7. 当决定后，秘书部需要告诉厂长——kubelet
8. 当有领导视察的时候，不知道飞机项目在哪个厂，则需要问门卫（门卫消息互通，问一个即可）——kube-proxy
9. 跟外部合作时，是外联部——Cloud controller manager
   

• 当厂长kubelet发现厂里有飞机项目做不下去了之后，就会发现并上报给秘书api-server，
• 秘书api-server再通报给决策者controller-manager说西厂的飞机项目搞不定了，
• 决策者说给别的厂搞把，于是告诉秘书，秘书再把决策存入数据库etcd，秘书再将决策通知调度者scheduler。
• 调度者随后动态地计算其他厂哪些适合搞飞机项目，其方案也会存入数据库etcd。
• 东厂每天都会和秘书通电话，当知道决策之后就会开始在东厂开始飞机项目

• 当整个项目搞起来，别人要访问则需要门卫大爷kube-proxy。
• 门卫大爷则负责接受传达消息。当其他项目如造船项目应用1需要参观造车项目应用3的时候，则去找门卫大爷，门卫大爷再告诉他应用三是在哪里。
• 故门卫大爷是打通整个网络访问的，谁想要访问、去哪访问
  
• 需要说明的是，整个集团架构，master总部其实是一个傀儡，真正决定的是程序员kubectl——挟天子以令诸侯
  

---------------------
作者：别出BUG求求了
来源：CSDN
原文：https://blog.csdn.net/weixin_39589455/article/details/124459859
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件