k8s学习笔记

目录

本文不具有任何学习价值，仅为个人学习记录

主要参考网址

  1. https://www.cnblogs.com/ccbloom/category/1460258.html 来自惊雪的博客
  2. http://docs.kubernetes.org.cn/
  3. 官方文档：https://kubernetes.io/docs/home/

主要参考网址1 来学习

k8s主要概念：

k8s中的 资源 、对象 有广义和狭义的概念

Serverless、容器编排工具、kubelet、kubeadm、kubectl、swap分区、负载均衡器、资源、对象、Pod、PID、IPC、

UTS名称空间、存储卷、Pod中的基础容器、etcd中存储、Master、Node、kubelet 、Service、标签Label、

标签选择器LabelSelector、Ingress、NameSpace（默认的是default）、Volume数据卷、NFS网络文件系统、RepliacationController、ReplicaSet、Deployment、StatefulSet、Daemon、Job、CronJob、

Registry、客户端Client

kube-apiserver、kube-scheduler、kube-controller、 replication-controller、etcd

一、云计算、容器化的演变

云计算的发展历程

  • IDC（Internet Data Center）：互联网数据中心
  • IaaS（Infrastructure as a Service）：基础设施即服务。IaaS提供商
  • PaaS（Platform as a Service）：平台即服务。PaaS提供商
  • SaaS（Software as a Service）：软件即服务。所有的东西都由 IaaS提供商提供，用户只管用
  • FaaS（Function as a Service）：函数即服务。Faas就是Serverless概念的一种体现。

Serverless

Serverless是无服务器架构，这并不是说不用服务器，而是通过技术手段将服务器透明化了，让开发者减少对服务器的关注。

  • 低成本：Serverless 将用户的服务器，数据库，中间件委托于FaaS。用户不再参与基础设施及软件的维护，而是直接使用相关资源
  • 按需计费：可按运行时间、请求次数等方式计费
  • 简化管理： 自动化弹性扩展、减小了打包和部署的复杂度，快速发布

容器化的演变

详细解释见网址1 中的 《Kubernetes（一）：容器编排介绍》

  • 传统服务 (即，单体架构)：项目过于臃肿、资源无法隔离、无法灵活扩展
  • 微服务：
    • 提高了管理复杂度：你单个服务过多时，互相之间的调用就是问题， 这就需要注册中心。
    • 客户端调服务端都需要一个统一的入口，就是API Gateway。
    • 其他特点 以及 上面两点的详细说明 见网址1
  • 容器化：
    • 容器概念的出现 比 微服务晚。近几年流行的 docker（容器技术中的一种），为微服务架构提供了有效的容器。
    • 且资源有效隔离是微服务的原则之一，而 docker 恰好能实现
      • 一般情况下，一个容器一个服务
      • 容器的资源隔离（PID、IPC、UTS 等等）、限制（CPU、Memory 等等）
      • 可扩展性、可移植性

二、容器编排工具

容器编排工具的概念：当容器数量达到一定规模，就需要编排工具去管理，就是容器生命周期管理工具。容器编排工具提供调度和管理集群的技术，提供用于基于容器应用可扩展性的基本机制。这些工具可决定容器之间如何进行交互

容器编排工具的核心价值：

  • 准备、部署容器
  • 容器的高可用、负载均衡
  • 应用规模的自动扩缩容
  • 底层硬件故障，能把容器迁移到其他节点商，用户无感知
  • 容器的资源分配
  • 容器的注册与自动发现
  • 容器和宿主机的健康检查
  • 容器配置和存储管理

容器编排工具种类

  • Docker Swarm：docker 自己的容器编排工具
  • Apache Mesos and Marathon：略
  • Kubernetes（k8s）：现在流行的

三、kubernetes 对象

简介

k8s简介：kubernetes（即 k8s），由 Google 的 go 语言编写。

k8s一大亮点就是自动化，在k8s的解决方案中，一个服务可以自我诊断、自我扩展、并且容易升级，在收到 服务扩容请求后，k8s会触发调度流程，最终在选定的目标节点上启动相应数量的服务实例副本，这些实例在启动后会自动加入负载均衡器。k8s 会定时巡查每个服务的所有实例的可用性，确保服务实例的数量与预期的数量一致，当它发现某个实例不可用时，会自动重启或在其它节点上重建该实例，整个过程无需额外的人工操作。

k8s 对象

资源：k8s 的 api 是一种RESTful 风格的API。在这种设计风格下，数据、服务等等一切都可以称之为 资源 。

对象：这些资源实例化后称之为 对象

比如：

  • Pod 在没有使用之前就是一个抽象的概念，称为 资源。
  • 你指定为 Pod 创建了容器之后，就可以称之为 对象

k8s 对象 —— 基础对象

  • Pod 对象：

    ​ 【最小部署单元、一个基础设施容器、N个容器、一个单独IP地址、普通Pod、静态Pod】

    • Pod --> k8s 最小部署单元，一个Pod可以包含一个或多个容器 业务内容就是部署在Pod里的容器
    • 每一个 Pod 中默认有一个基础设施容器 infrastructure container，后续添加进来的容器共享此容器的 资源(Network、IPC、共享网络设备、网络协议、主机名、域名等)。因此同一个 Pod 中的 容器可以通过 IO 互相通信。还而可以选择 共享基础容器的 存储卷
    • 每一个 Pod 都会被分配一个单独的IP地址，且每个 Pod 都提供了Endpoint（Pod IP + Container Port）以被 客户端访问
    • Pod 分为 普通pod 和 静态Pod
      • 普通Pod： 一旦被创建，就会被放进 etcd 中存储，随后会被 Master 调度到某个 Node 上并进行绑定，随后会被 对用 Node 上的 kubelet 实例化成一组容器并运行起来。如果Pod所在的Node宕机了，Master会将这个Node上的所有Pod重新调度到其它Node节点上
      • 静态Pod：不会存储到 etcd 中，而是存放在某个 Node 节点上的一个具体文件中，并且只在此 Node 上启动

  • Service 对象：一组 Pod 的抽象

    • service 是一组 Pod 的抽象，每个 Service 都有一个唯一的名字，并被分配一个虚拟 IP（Cluster IP、Service IP或VIP）。
    • Service通过代理后端Pod对外或者对内提供访问，就好比nginx和后端服务的关系。来自这个IP的请求都会经过调度后转发给后端Pod中的容器。
    • Service 通过 标签选择器[LabelSelector] 去选择一组 Pod 提供服务

  • 标签Label 对象：用于区分对象。

    • 使用标签引用对象，而不再是IP地址。

      • 假设Service代理一个或者多个Pod，但是某一个Pod因故障被删重新调度出一个新Pod，那么这个Pod的IP可能会发生改变，因为容器的IP是随机的。那Service怎么能知道这个新Pod的IP呢。这时使用标签就可以完美的解决问题。
      • 在最初创建Pod时，它的Label就已经写死了，当然后面是可以手动改的。
      • 即便重建了Pod，IP变了，Label不会变。

    • 每个对象可以有多个标签，通过标签可以关联对象。

      ​ （如：给一个人贴多个标签，通过标签可以联想到某人）

    • 标签 以键值对的形式存在。 比如 app: nginx

      • Service通过 LabelSelector 去找 Label 为 app:nginx 的 服务 依然能够找到（无论服务的IP是否改变）。

  • Ingress 对象： 给 Service 提供外部访问功能

  • NameSpace 对象： 可以理解为 对象的集合

    • 比如 Pods、Services 都是属于某一个 Namespace 的 （默认是default）。

  • Volume 对象： 数据卷，共享 Pod 中使用的数据

    • 可以是本地目录、本地磁盘、NFS网络文件系统(七牛云就是一种)、等等

k8s 对象 —— 高级对象

  • ReplicationController 对象： 使用它来确保Pod以用户指定的副本数量运行。容器异常或者缺少都会自动处理。
  • ReplicaSet ： ReplicationController 的替代物。
    • RC与RS唯一区别就是支持LableSelector不同，RS支持基于集合的标签。
    • 官方建议使用Deployment来自动管理RS，因为有些功能RS不支持，Deployment支持。
  • Deployment： Pod 控制器，它支持版本记录、回滚、暂停升级等高级特性。
    • Pod是不可以被直接创建的，需要先创建控制器，然后由控制器去创建Pod。每个Pod都对应一个deployment控制器。
  • StatefulSet ： 为解决有状态服务的问题（对应 Deployments 和 ReplicaSets是为无状态服务而设计）
  • DaemonSet ： 保证在每个 Node 节点上都运行一个 Pod，常用来部署些集群的 日志、监控等应用。
    • 比如 fluentd、logstash、Prometheus 等等
  • Job： 一次性任务，运行完后 Pod 销毁，不再自动重建
  • CronJob： 定时任务

k8s 组件

整个 Kubernetes 集群大致划分为四个部分：Clients，Master，Node，Registry。k8s本身其实就 Master 和 Nodes 两部分

  • Master： 是 k8s 集群的管理节点，是提供集群访问与管理的唯一入口。只有一个Master节点
  • Nodes： 是 k8s 集群的运行 Pod 的服务节点，实际上也就是运行 容器。可以有多个Node节点
  • Registry： 容器的运行需要的依赖于镜像
  • Client： 编程接口、图形化接口、命令行接口。通过这些接口向 Master 发请求来管理容器，
    • 比如：创建容器的请求、删除等操作。发起请求者 就是 客户端Client

img

k8s 组件 —— Master 的组件

Master 节点有 四个核心组件，每一个组件都是单独的服务。

  1. kube-apiserver ： 是整个 k8s 集群对外提供服务的唯一入口。

    • 作用：请求过滤、访问控制等机制、协调各组件
    • 此API是声明式的（简单说就是用户想要什么规格的容器直接跟kube-apiserver说就行了，过程不用你管）。用户的合法请求会被 API 放行，然后存入 etcd 中。
      1. 是否合法指定的是：k8s将etcd所能接受的数据规格范式加以封装定义在了kube-apiserver中，符合规格才能放行。
      2. 程序的编程范式包括声明式和命令式。声明式强调结果、命令式(编程式)强调过程

  2. kube-scheduler： 资源调度器。

    kube-apiserver收到新建Pod的请求，识别其合法并存入etcd， 然后 kube-scheduler 去 watch(监视) kube-apiserver知道此需求，根据 预定的调度策略 评估一个最合适 Node 节点来运行Pod，如果没有最合适，那就随机，最后会把调度的结果记录在 etcd 中。

  3. kube-controller： 控制器。

    ​ 负责维护集群的状态、故障检测与恢复、自动扩展、节点状态等等。

    ​ kube-controller有一个control loop的机制，它会循环检测集群中Pod的状态，假如Nginx启的不是预期的80端口，那就由kube-controller来控制容器重启、重建，直到达到预期效果为止。

  4. replication-controller：

    管理维护Replication Controller，关联Replication Controller和Pod， 保证 Replication Controller定义的Pod副本数量与实际运行Pod数量一致。

  • 举例：用户发送新建Nginx容器的请求给kube-apiserver，kube-apiserver识别其合法后以键值对的方式存入etcd，kube-scheduler和kube-controller通过watch kube-apiserver知道此需求，然后kube-scheduler负责资源分配并决定容器运行在哪个Node上，至于运行时所需的镜像及运行的健康状态的维护都由kube-controller来负责，kube-controller会循环将当前容器的状态与watch到的用户预期的需求做对比，看是否匹配。
    • k8s watch功能：k8s提供的watch功能是建立在 etcd 之上的。现在是当etcd中的键值发生变化时，通知kube-apiserver，其它的组件需要watch时去直接找kube-apiserver

​

其他

  • etcd：是一个键值对格式的 存储系统，保存应用程序配置信息

k8s 组件 —— Node 的组件

​ Node节点负责运行容器。k8s支持多种容器引擎，一般使用 docker 容器引擎

  • kubelet： 它也还会去 监听(watch) kube-apiserver。如果发现有新任务的调度结果分到自己这个 Node 节点上，便会执行此任务，并将结果 返回给 kube-apiserver
    • kubelet 运行在集群的所有节点上，负责启动 Pod 和容器
  • docker：容器组件。假如 kubelet 接过来的任务是创建容器，那 kubelet 就会调 docker组件在本节点上创建
  • container runtime： 负责pod 和 容器的运行，即 k8s的 cri 接口。咱忽略此组件
  • kubeletes-proxy：是用来维护Service网络。根据Service的信息创建代理服务，实现Service到Pod的请求路由和转发，本身也有负载均衡功能。支持 iptables 和 ipvs 两种模式。

Addons

除了上面Master和Node的几个核心组件，还有下面一些扩展插件，其中有些插件是非必须的。

  • Coredns：维护Service与cluster ip之间的对应关系
  • CNI：容器网络接口。k8s的网络模型需要借助插件才能实现，比如flannel，calico等，flannel插件就是用来维护Pod网络的。
  • Web UI（Dashboard）：图形界面，并非必须。
  • Fluentd：为集群提供日志采集、存储和查询。
  • Traefik：Ingress Controller的软件实现，为pod中服务提供外网访问。
  • Dashboard：管理k8s的图形化界面。

四、k8s 部署

4.1 部署环境

  • 公有云环境：AWS、腾讯云、阿里云等等
  • 私有云：OpenStack、vSphere等
  • Baremetal环境：物理服务器或独立虚拟机（底层没有云环境）

4.2 部署方式

  • Minikube：
  • Kubeadm： 这种方式其实是将 k8s 的各组件容器化了。 生产环境不适用
  • 二进制部署： 生产环境适用。将重要组件以守护进程的方式部署
  • 还有一些云厂商专有的部署方式，如 kops。
  • 二次封装的k8s发行版

4.3 部署要点

略！见网址1

4.4 部署步骤

详情见网址1

  • 主机规划：master节点的主机、（N个）数据Node节点的主机
  • 准备工作：略
  • 安装程序：所有节点上安装必要的程序
  • 修改配置并初始化集群： 即，建立 master 节点
  • 配置Node节点加入到k8s集群 ：即，添加 Node 节点

五、kubectl 常用操作

略！见网址1、网址2

posted @ 2020-07-07 00:41  roronoa_wang  阅读(194)  评论(0)  编辑  收藏  举报