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

王小希ww

已于 2022-07-10 14:45:54 修改

阅读量927

点赞数 2

分类专栏：技能树云计算 # docker 文章标签：云原生 java 开发语言

于 2022-06-28 20:43:29 首次发布

本文链接：https://blog.csdn.net/qq_33934427/article/details/125509469

版权

技能树同时被 3 个专栏收录

26 篇文章 6 订阅

订阅专栏

云计算

10 篇文章 0 订阅

订阅专栏

docker

10 篇文章 0 订阅

订阅专栏

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

Note：根据 CSDN云原生技能树整理的题目。

文章目录

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

一、容器（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 容器编排

k8s 三件套：kubelet, kubectl, kubeadm，可参考深入剖析Kubernetes
k8s 基础组件介绍，可参考K8s架构|全面整理K8s的架构介绍
k8s 设计理念，参考Kubernetes 核心理解之声明式API和编程范式

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 流量管理的实战文档：
- 配置请求路由(request-routing)：如何将请求动态路由到微服务的多个版本。
- 故障注入(fault-injection)：此任务说明如何注入故障并测试应用程序的弹性。
- 流量转移(traffic-shifting)：展示如何将流量从旧版本迁移到新版本的服务。
- TCP 流量转移(tcp-traffic-shifting)：展示如何将一个服务的 TCP 流量从旧版本迁移到新版本。
- 设置请求超时(request-timeouts)：本任务用于示范如何使用 Istio 在 Envoy 中设置请求超时。
- 熔断(circuit-breaking)：本任务展示如何为连接、请求以及异常检测配置熔断。
- 镜像(mirroring)：此任务演示了 Istio 的流量镜像/影子功能。
- 地域负载均衡(locality-load-balancing)：本系列任务演示如何在 Istio 中配置地域负载均衡。
- Ingress：控制 Istio 服务网格的入口流量。
- Egress：控制 Istio 服务网格的出口流量。
istio安全控制：
- 认证：管控网格服务间的双向 TLS 和终端用户的身份认证。
- 证书管理：管理 Istio 的证书。
- 授权：展示如何控制到 Istio 服务的访问。
istio 可观察性的操作任务：
- 指标度量(metrics)：演示 Istio 网格指标度量的配置、收集和处理。
- 日志(logs)：演示 Istio 网格日志的配置、收集和处理。
- 分布式追踪(distributed-tracing)：该任务展示了如何为启用了 Istio 支持的应用进行追踪。
- 网络可视化(kiali)：此任务向您展示如何在 Istio 网格中可视化服务。
- gateways：此任务向您展示如何配置从外部访问 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 可以让基础设施的构建使用上声明式配置，具有标准化、统一配置、减少错误、跨平台的好处。