云原生题目整理(待更新)

10 篇文章 0 订阅
10 篇文章 0 订阅

云原生题目整理(待更新)

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

一、容器(docker)

二、容器编排(k8s)

1)学习环境 K8s 容器编排

Note

  • kubectl 是用来与 Kubernetes 集群通讯的命令行工具。通过 Kubectl 可以在 Kubernetes 集群上完成如下操作:
    • 部署和管理应用
    • 查看资源信息
    • 删除和更新组件
  • 学习阶段,在个人主机上安装和配置 kubernetes 有两个可选的套装:kind 或者 minikubekubernetes管理工具,这两者不会安装 kubectl,因此kubectl是需要独立安装的。
    minikubekind 会自动安装 kubelet,但是 kubeadm 不会自动安装kubelet
  • K8s中主机(物理机/云主机/虚拟机)主要分为两种 MasterNode
    • Node 是运行具体容器的主机,负责提供后具体的服务,并且本身具有自我修复能力 –Data Plane 数据平面
    • Master 负责管理Node, 控制Node 具体运行什么容器, 同时还承担外部数据访问的角色-- Control Plane 控制层面
  • Mater由四个逻辑组件组成, 他们分别由四个独立的守护线程, API Server, SchedulerController是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

  • kubeletkubelet计算节点上最核心的组件(对Borg项目中的Borglet进行改进),主要负责同容器运行时(比如Docker项目)打交道;而这个交互所依赖的,是一个称作CRI(Container Runtime Interface)的远程调用接口,这个接口定义了容器运行时的各项核心操作kubelet还通过gRPC协议同一个叫作Device Plugin的插件进行交互。
    kubelet的另一个重要功能,则是调用网络插件存储插件为容器配置网络和持久化存储。
    在理解了容器技术之后,你可能已经萌生出了这样一个想法,为什么不用容器部署K8s呢?但这样做会带来一个很麻烦的问题,即如何容器化kubelet; 到目前为止,在容器里运行kubelet,依然没有很好的解决办法,所以不推荐使用容器去部署Kubernetes项目。
    因此,下面提到的kubeadm选择了一种妥协方案:把kubelet直接运行在宿主机上,然后使用容器部署其他的K8s组件
  • kubeadmkubeadm可以实现一键部署。主要包括kubeadm initkubeadm 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之后,你就可以在任意一台安装了kubeletkubeadm的机器上执行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-proxyAPI Server 通信在ServiceMesh下,每个pod直接通过装在pod上的proxy和API Server通信
    2)原来k8s的node里的pod通过node的kube-proxy桥接通信;在ServiceMesh下,每个 pod 之间直接通过装在 pod上的proxy直接通信
  • 在k8s原生组件的基础上,给每个pod安装服务网格的proxy,对这些proxy的编排调度,构成里服务网格层。服务网格的特点是,将微服务管理功能内置到基础架构层,无需在应用层写相关代码。
  • istio服务网格基础设施的一种实现,支持在多个不同的云原生基础设施上工作。
  • 下面是一组 istio 流量管理的实战文档:
  • istio安全控制
    • 认证:管控网格服务间的双向 TLS 和终端用户的身份认证。
    • 证书管理:管理 Istio 的证书。
    • 授权:展示如何控制到 Istio 服务的访问。
  • istio 可观察性的操作任务

五、持续集成和部署(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是常见的做法,并且具有高可用
  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值