云原生题目整理（待更新）

云原生题目整理（待更新）

Note ：根据 整理的题目。

文章目录

一、容器（docker）

二、容器编排（k8s）

1）学习环境 K8s 容器编排

• ，可参考
• ， ，可参考
• ， ，可参考
• ，可参考
• ，可参考 ，
• ，可参考

Note ：

• kubectl 是用来与 Kubernetes 集群通讯的命令行工具。通过 Kubectl 可以在 Kubernetes 集群上完成如下操作：

  • 部署和管理应用
  • 查看资源信息
  • 删除和更新组件

• 学习阶段，在个人主机上安装和配置 kubernetes 有两个可选的套装： kind 或者 minikube 的 kubernetes 管理工具，这两者不会安装 kubectl ，因此 kubectl 是需要独立安装的。

  minikube 和 kind 会自动安装 kubelet ，但是 kubeadm 不会自动安装 kubelet

• K8s中主机（物理机/云主机/虚拟机）主要分为两种 Master 和 Node

  • Node 是运行具体容器的主机,负责提供后具体的服务,并且本身具有自我修复能力 – Data Plane 数据平面
  • Master 负责管理Node, 控制Node 具体运行什么容器, 同时还承担外部数据访问的角色– Control Plane 控制层面

• Mater 由四个逻辑组件组成, 他们分别由四个独立的守护线程, API Server , Scheduler 和 Controller 是K8s自己做的, etcd 则是使用 Core OS的成果。

  • etcd

    用户保存应用程序 配置信息的守护进程 ,是一个 k-v存储系统 ,存储内容为用用户发出的API请求中容器的具体要求, 是一个强一致性的。

  • API Server

    是 K8s开放给用户的唯一入口 , 接受用户的指令。同时对指令进行规范检查, 如果合乎规范的话将其放入 etcd 中。

  • Scheduler

    是作为调度器，负责的内容是 寻找要部署的容器的最佳Node . 主从模式, 只能有一个正在执行的服务。

  • Controller

    是作为控制器, K8s提供的API是声明式API 。要运行一个redis容器, 只需要声明要运行一个redis容器即可, 具体的镜像来源以及挂掉后重启等等都有控制器完成。 控制器负责用户指令的具体运行以及保证资源运行 一直符合用户的需求, 作为 Master 的大脑， 也只能有一个正在执行的服务。

• Node 节点是作为K8s中的 工作负载节点 , Node 节点接收 Master 节点分配的一些任务，Node的关键组件：

  • kubelet

    负责 对pod(POD是一组 )对应容器的创建 ，启停等一系列的任务, kubelet 时刻watch着 Mater 中的API Server中的资源变动, 当有和自己相关的任务的时候就会调用Docker执行具体的任务。

  • kube-proxy

    用于实现 K8S Service(需要提供的服务) 的通信和负载均衡

  • Docker Engine

    docker引擎, 负责Node于和容器有关的操作, K8s原生支持Docker作为容器引擎 , 如果要使用其他容器引擎则需要使用对应接口集成。

  • Pod

    K8s不是直接运行的容器,而是操作Pod, 把Pod作为原子单元管理 ,一个Pod里面可能会运行多个容器, Pod里面运行的多个容器被捆绑在一起被统一调度不可分割 ，一个Pod的所有容器只能同时运行在一个 Node 上。

• ReplicaSet 通常包含多个Pods，Pod是一个或多个容器的组合 ，这些容器共享存储、网络和命名空间，以及如何运行的规范。

• 通过 deployment 可以部署一个 ReplicaSet，deployement 可以通过 service 暴露给集群外。

2）生产环境 K8s 容器编排

• ，可参考
• ，可参考
• ，参考

Note ：

• kubelet ： kubelet 是 计算节点 上最核心的组件（对Borg项目中的 Borglet 进行改进）， 主要负责同容器运行时 （比如Docker项目）打交道；而这个交互所依赖的，是一个称作 CRI （Container Runtime Interface）的远程调用接口，这个接口定义了 容器运行时的各项核心操作 ； kubelet 还通过 gRPC协议 同一个叫作 Device Plugin 的插件进行交互。

  kubelet 的另一个重要功能，则是调用 网络插件 和 存储插件 为容器配置网络和持久化存储。

  在理解了容器技术之后，你可能已经萌生出了这样一个想法， 为什么不用容器部署K8s 呢？但这样做会带来一个很麻烦的问题，即 如何容器化 kubelet ; 到目前为止，在容器里运行 kubelet ，依然没有很好的解决办法，所以不推荐使用容器去部署 Kubernetes 项目。

  因此，下面提到的 kubeadm 选择了一种妥协方案：把 kubelet 直接运行在宿主机上，然后 使用容器部署其他的K8s组件 。

• kubeadm ： kubeadm 可以实现一键部署。主要包括 kubeadm init 和 kubeadm join 指令

  kubeadm 首先要做的，是一系列的检查工作，以 确定这台机器可以用来部署K8s ；

  在通过了 Preflight Checks 之后， kubeadm 要做的，是 生成K8s对外提供服务所需的各种证书和对应的目录 ；证书生成后， kubeadm 会为其他组件 生成访问kube-apiserver所需的配置文件 ；接下来， kubeadm 会 为Master组件生成Pod配置文件 ；然后， kubeadm 就会为集群生成一个bootstrap token，接着 kubeadm 会将 ca.crt 等Master节点的重要信息，通过 ConfigMap 的方式保存在 Etcd 当中，供后续部署 Node 节点使用。

  kubeadm init 生成bootstrap token之后，你就可以在任意一台安装了 kubelet 和 kubeadm 的机器上执行 kubeadm join 了。

• kubectl ：kubectl是kubenetes 命令行工具 ，通过 kubectl 可以部署和管理应用，实现 k8s集群通讯 ，查看各种资源，创建，删除和更新组件。

三、k8s包管理（helm）

• ，参考

Note ：

• 相较于centos 上的 yum ，ubuntu 上的 apt-get ，Windows 上的 choco 包管理软件，k8s 上也可以通过 helm （k8s 的包管理软件），给 k8s 平台安装各种组件包或者服务包。
• helm 通过三大概念来管理 k8s 上的包:
  • Chart ：Chart 代表着 helm 包。它包含在 K8s 集群内部运行应用程序 ，工具或服务所需的所有 资源定义 。
  • Repository ：是 chart 的存储库。例如：https://charts.bitnami.com/bitnami
  • Release ：Release 是运行在 K8s 集群中的 chart 的实例。 一个 chart 通常可以在同一个集群中安装多次 。每一次安装都会创建一个新的 release。以 MySQL chart为例，如果你想在你的集群中运行两个数据库，你可以安装该chart两次。每一个数据库都会拥有它自己的 release 和 release name。
• kubectl 命令可以部署应用， helm 也可以部署应用，而且 helm 部署的应用也可以通过 kubectl 管理。

四、服务网格（istio）

• ，参考
• ， ，参考 ，

Note ：

• 客户端请求网页常常会经过代理，代理请求后面的服务，后台服务返回给代理，代理再返回给客户端。这是一个典型的代理服务的情景。大概是这样：

  Client <-> Proxy <-> Server

  现代后端开发，将服务拆分成多个微服务是常见的做法。

  Client <-> Interface <-> [ProxyA->ServerA] <-> [ProxyB->ServerB]

  Client <-> Interface <-> [ProxyB->ServerB] <-> [ProxyA->ServerA]

• 微服务之间的互相访问 ，公共的代理部分可以做很多 公共的控制逻辑 。这部分的的代码标准化，下层到云原生的基础设施里，就形成了服务网格（ServiceMesh）。 服务网格通常管理微服务 之间这三个方面的功能：

  • 流量管理 (Traffic management)： 动态服务发现 、路由、 流量灰度 和流量分离等。
  • 安全 (Security)：加密传输、基于 正式验证的授权 、基于访问控制和网络分区的授权等。
  • 可观察性 (Observability): 例如链路跟踪、日志等。

• 服务网格和 k8s 之间是什么关系呢？一图胜千言，在k8s的基础上，为每个pod增加一个proxy（或者叫边车，sidecar)，有两个变化：

  

  1）原来k8s的node里的pod通过node的 kube-proxy 和 API Server 通信 ； 在ServiceMesh下，每个pod直接通过装在pod上的proxy和API Server通信 。

  2）原来k8s的node里的pod通过node的 kube-proxy 桥接通信 ；在 ServiceMesh 下，每个 pod 之间直接 通过装在 pod上的proxy直接通信 。

• 在k8s原生组件的基础上，给每个pod安装服务网格的proxy， 对这些proxy的编排调度，构成里服务网格层 。服务网格的特点是， 将微服务管理功能内置到基础架构层 ，无需在应用层写相关代码。

• istio 是 服务网格基础设施的一种实现 ，支持在多个不同的云原生基础设施上工作。

• 下面是一组 istio 流量管理 的实战文档：

  • ： 如何将请求动态路由到微服务的多个版本。
  • ：此任务说明如何注入故障并测试应用程序的弹性。
  • ： 展示如何将流量从旧版本迁移到新版本的服务。
  • ： 展示如何将一个服务的 TCP 流量从旧版本迁移到新版本。
  • ：本任务用于示范如何使用 Istio 在 Envoy 中设置请求超时。
  • ：本任务展示如何为连接、请求以及异常检测配置熔断。
  • ：此任务演示了 Istio 的流量镜像/影子功能。
  • ：本系列任务演示如何在 Istio 中配置地域负载均衡。
  • ：控制 Istio 服务网格的入口流量。
  • ：控制 Istio 服务网格的出口流量。

• istio安全控制 ：

  • 认证 ：管控网格服务间的双向 TLS 和终端用户的身份认证。
  • 证书管理 ：管理 Istio 的证书。
  • 授权 ：展示如何控制到 Istio 服务的访问。

• istio 可观察性的操作任务 ：

  • ：演示 Istio 网格指标度量的配置、收集和处理。
  • ：演示 Istio 网格日志的配置、收集和处理。
  • ：该任务展示了如何为启用了 Istio 支持的应用进行追踪。
  • ：此任务向您展示如何在 Istio 网格中可视化服务。
  • ：此任务向您展示如何配置从外部访问 Istio gateways。

五、持续集成和部署（Jenkins）

• ，参考 ， ，

Note ：

• Jenkins 是一个可伸缩的，持续集成，持续部署的 软件自动化工具 ， jenkins 可以 部署在 k8s 内，也可以部署在k8s外 ；在k8s 内部署 jenkins ，使得其自动获得了 高可用 。
• 登陆 jenkins 后 ，可以配置一系列 CI/CD 动作：

  • CI

    1）拉取代码

    2） 构建/测试/打包

    3） 构建容器镜像

  • CD

    1）推送容器镜像到 镜像中心

    2）执行 k8s命令，拉取镜像

    3）执行k8s命令，部署

    4）执行k8s命令，滚动更新

六、基础架构自动编排（Terraform）

• ，参考

Note ：

• Terraform 是一种安全有效地构建、更改和版本控制的 基础设施管理工具 (基础架构自动化的编排工具)，它的目标是 Write, Plan, and create Infrastructure as Code , 基础架构即代码 ，允许我们以代码的方式构建、更改和管理基础设施。 Terraform 并不局限于任何特定的云服务提供商，它可以与多个云提供商和环境协同工作，虽然 Azure,AWS 分明有针对自己云平台的资源管理、设置的解决方案。

• Terraform 能够让您在云上轻松 使用 简单模板语言 来定义、预览和部署云基础结构 。您可以使用 Terraform 来 创建、修改、删除ECS、VPC、RDS、SLB等多种资源 。

  可以从两个方面来简化理解:

  1） Terraform 采用声明式方式配置基础架构设置

  2） Terraform 提供了对规范的基础架构配置的命令行操作

• Terraform 对基础架构的管理 3个步骤:

  1）

  Write

  编写基础架构的配置

  2）

  Plan

  对配置进行校验

  3）

  Apply

  将配置在多云上实施、生效

• 使用 Terraform 可以让基础设施的构建 使用上声明式配置 ，具有标准化、统一配置、减少错误、跨平台的好处。

七、云原生环境小结

Note ：

• 云原生下的编程，核心是将应用程序打包成容器镜像
• 云原生下的编程，容器镜像可以被部署到 k8s 的node里的pod上运行
• 云原生下的编程，天生上是分布式的程序
• 云原生下的编程，传统分 布式服务架构的很多开发工作都已经被下层到k8s或者服务网格基础设施层 。
• 云原生下的编程，有大量的对 yaml 做声明式配置的工作
• 云原生下的编程，CI/CD是常见的做法，并且具有高可用