愿景："让编程不再难学，让技术与生活更加有趣" xdclass.net

第一章 架构师系列-容器编排调度K8S最佳实践专题课程介绍

第1集 架构师系列-容器编排调度K8S最佳实践专题课程介绍

简介：架构师系列-容器编排调度K8S最佳实践专题课程介绍-课程适合人员和学后水平

• 课程介绍

  • 本套课程 是全新录制，从0到1讲解新版kubernetes核心基础+高级知识点+可视化管理工具Rancher实战

  • 核心介绍

    • 从0到1教你掌握kubernetes核心组件，基于互联网项目部署方式演进，到整体容器编排调度组件架构。
    • 使用阿里云ECS服务器多种方式搭建K8S集群，搭建MiniKube、KubeAdm等方式，5分钟带你部署第一个K8S应用
    • 从k8s核心资源文件yaml解析到多个资源实战，包括 Pod、Label标签、NodeSelector选择器综合应用
    • Pod控制器Deployment实现滚动升级、DeamonSet、Job等案例实战；
    • 服务注册发现Service多类型ClusterIP、NodePort等应用；
    • 数据存储持久化劵Volume实战，包括ConfigMap、Secret、NFS、PV、PVC多案例
    • 基于当下热门框架SpringBoot+JDK11打包镜像，推送私有镜像仓库+K8S集群部署实战
    • 互联网大厂DevOps链路解析，热门K8S可视化管理工具Rancher2.X实战，部署私有镜像SpringBoot应用和热门中间件Redis7、Mysql8.0实战
    • 基于Kubectl操作对比Rancher管控台和备份导出，是一套从0学K8S到实战的快速上手课程

     

• 为什么要学习容器编排调度Kubernetes

  • 多数互联网公司里面用的技术，实现跨主机多容器编排调度管理的最佳技术之一

  • 可以实现服务注册发现、DevOps自动部署和回滚，能够自动实现请求的负载均衡分配网络流量

  • 在多数互联网公司中，Kubernetes占有率很高，是近几年大量流行

  • 可以作为公司内部培训技术分享必备知识，超多案例+实战等

  • 有谁在用，进一线大厂（国内大厂多数都有用 ）

    • 国内：阿里、字节、腾讯 、微信、网易、虎牙、青云、新浪等
    • 国外：谷歌、Facebook、亚马逊、苹果等

• 如果你想成为下面的一种，则这个课程是必备

  • 后端高级开发工程师-大数据工程师
  • 技术leader或者架构师
  • 从传统软件公司过渡到互联网公司的人员
  • 高级运维工程师 或 高级测试工程师

• 课程技术栈和测试环境说明

  • 阿里云Linux CentOS 7服务器

  • 技术不断更新，版本如何选择（跟着课程走，主流版本）

    • 技术框架版本使用这块，不建议做第一个吃螃蟹的人
    • 不同中间件，厂商不一样，不一定及时更新

     

• 学后水平

  • 掌握kubernetes核心组件，基于互联网项目部署方式演进，到整体容器编排调度组件架构。
  • 掌握阿里云ECS服务器多种方式搭建K8S集群，搭建MiniKube、KubeAdm等方式
  • 掌握k8s核心资源文件yaml解析到多个资源实战，包括Pod、Label标签、NodeSelector选择器综合应用
  • 掌握Pod控制器Deployment实现滚动升级、DeamonSet、Job等案例实战；
  • 掌握服务注册发现Service多类型ClusterIP、NodePort等应用；
  • 数据存储持久化劵Volume实战，包括ConfigMap、Secret、NFS、PV、PVC多案例
  • 基于当下热门框架SpringBoot+JDK11打包镜像，推送私有镜像仓库+K8S集群部署实战
  • 互联网大厂DevOps链路解析，热门K8S可视化管理工具Rancher2.X实战，部署私有镜像SpringBoot应用和热门中间件Redis7、Mysql8.0实战
  • 基于Kubectl操作对比Rancher管控台和备份导出，是一套从0学K8S到实战的快速上手课程

   

   

• 学习形式

  • 视频讲解 + 文字笔记 + 原理分析 + 交互流程图
  • 配套源码 + 笔记 + 技术群答疑( 我答疑，联系客服进群)
  • 只要是我的课程和项目-我会一直维护下去，大家不用担心！！！

• 【必做事情】更多技术问题+职业规划，可以加我微信

  • 本职工作在比较忙，搬砖+带团队, 没法秒回，有空但都会很快回复的，见谅哈

第2集 架构师系列-容器编排调度K8S最佳实践课程大纲速览

简介：架构师系列-容器编排调度K8S最佳实践课程大纲速览

• 课程学前基础

  • 有Linux+docker就行，不会的话我们有专题课程学习,联系客服小姐姐即可
  • 框架整合这块：采用SpringBoot框架（采用其他语言或框架也行）

• 目录大纲浏览

• 学习要求：

  • 课程有配套资料，如果有用到就会在对应章集的资料里面，如果自己操作的情况和视频不一样，仔细对比对比验证基本就可以发现问题了

  • K8S配置多，所以遇到和课程效果不一样的，建议看多几次，结合笔记里面的配置

  • 重点先把概念+解决方案掌握

  • 不同岗位对K8S的侧重点

    • 后端/前端/测试/工程师、架构师 把这个k8s掌握即可
    • 容器开发/运维工程师 可以做一个快速入门，后续可以找学习k8s底层原理这块知识

     

• 保持谦虚好学、术业有专攻、在校的学生，有些知识掌握也比工作好几年掌握的人厉害

• 文档

  • K8S文档：https://kubernetes.io/docs/home/

     

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第二章 互联网项目部署方式演进和K8S快速认知

第1集 老王的经历-互联网项目部署方式演进历史发展

简介：老王的经历-互联网项目部署方式历史发展

• 相信大家对K8S是又爱又恨

  • 所谓爱的深、痛的深
  • 爱：互联网大厂广泛使用，功能强大
  • 痛：概念多、又抽象、底层复杂

• 应用程序部署方式

  

  • 传统部署时代：

    • 早期的时候，在物理服务器上运行应用程序

    • 缺点

      • 无法限制在物理服务器中运行的应用程序资源使用，会导致资源分配问题，过高或过低
      • 部署多个物理机，维护许多物理服务器的成本很高。

       

  • 虚拟化部署时代：

    • 虚拟化技术允许在单个物理服务器的 CPU 上运行多台虚拟机（VM）。

    • 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性

    • 能够更好地利用物理服务器的资源，具有更高的可伸缩性，以及降低硬件成本等等的好处

    • 缺点

      • 需要单独一个系统，占用资源
      • 不能灵活的扩容和缩容

   

  • 容器部署时代：

    • 容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）

    • 最熟悉的就是Docker容器化技术

      • 一行命令可以部署任意一个 mysql、nginx、redis、RabbitMQ、Kakfa等热门中间件
      • docker命令可以操作当前机器上的1个容器
      • docker-compose可以操作当前机器上的多个容器

    • 容器比起 VM 被认为是更轻量级的，每个容器都具有自己的文件系统、CPU、内存、进程空间等。

    • 跨云和操作系统发行版本的可移植性：可在 Ubuntu、CoreOS、CentOS、 Google Kubernetes Engine 和其他任何地方运行

       

• 那Docker容器化技术带来了哪些问题

• 更多技术问题+职业规划，可以加我微信（本职工作比较忙，没法秒回，见谅）

第2集 容器化带来的问题和Kuberntes快速认知

简介：容器化带来的问题和K8S快速认知

• 容器化部署存在的问题

  • 问题

    • 10个物理机发布100个容器，怎么快速发布和管理
    • 用户请求过来，怎么分配请求到100个容器里面
    • 突发海量请求过来，如何根据情况进行快速扩容
    • 应用发布上线出现问题，需要进行回滚历史版本，如何进行回滚
    • 某个容器故障了，如何快速启动新容器去替代
    • ....

  • 上面容器管理的问题称为容器编排，为了解决这些问题，产生了一些容器编排的软件

    • Docker Swarm：Docker自己的容器编排工具
    • Mesos：Apache的资源管控的工具，结合Marathon使用
    • Kubernetes：Google开源的的容器编排工具, 基于内部Borg系统的开源版本

     

• 什么是Kubernetes？

  • Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。
  • k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。
  • Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。
  • Kubernetes是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，简称 K8S
  • 官方文档：https://kubernetes.io/zh-cn/docs/home/

• 不说那么多废话了

  • K8S的本质是一组服务器集群，可以在对应服务器集群的每个节点上运行程序，来对节点中的容器进行管理。
  • 类似Master-Work方式，每个服务器上安装特定的k8s组件，就可以形成集群，然后部署对应的应用即可。

• k8s常见的功能：

  • 服务发现和负载均衡

    • Kubernetes 可以使用 DNS 名称或自己的 IP 地址来暴露容器。
    • 如果进入容器的流量很大， Kubernetes 能够自动实现请求的负载均衡分配网络流量，从而使部署稳定

  • 存储编排

    • Kubernetes 允许自动挂载选择的存储系统，例如本地存储、云提供商存储等。

  • 自动部署和回滚

    • 可以用k8s自动化部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。
    • 当版本发布错误，可以立刻回退到之前的版本

  • 自我修复

    • 如果某个容器宕机了，K8S 可以快速重新启动新的的容器，替换旧的容器

  • 密钥与配置管理

    • K8S允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥

       

第3集 Kubernetes常见概念组件和整体架构讲解《上》

简介：Kubernetes常见组件和整体架构讲解《上》

• K8S整体架构，也是Client-Server模型

  • 控制节点Master-Node，负责集群的管理
  • 工作节点Worker-Node，负责为集群提供运行环境

• kubernetes常见概念

  • Master

    • 指的是集群控制节点（相当于整个集群的指挥中心），在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制

   

  • Node

    • 除了master，k8s集群中的其他机器被称为Node节点，Node节点才是kubernetes集群中的工作负载节点
    • 每个Node节点都会被master分配一些工作负载（docker容器），node节点上的docker负责容器的运行

   

  • Pod

    • Pod是一组容器, 在K8S中，最小的单位是Pod, 一个Pod可以包含多个容器，但通常情况下我们在每个Pod中仅使用一个容器

    • 可以把Pod理解成豌豆荚, Pod内的每个容器是一颗颗豌豆

    • 分类

      • 自主创建：直接创建出来的Pod，这种pod删除后就没有了，也不会自动重建
      • 控制器创建：通过控制器创建的pod，这类Pod删除了之后还会自动重建

       

    

  • Pod Controller

    • 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod在运行中出现故障，它会基于指定策略重新编排Pod

    • 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等

    • 类型

      • ReplicaSet、Deployment、Horizontal Pod Autoscaler、DaemonSet等

   

  • Service

    • 在k8s里面，每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失
    • Service (服务)就是用来解决这个问题的, 对外服务的统一入口，用于为一组提供服务的Pod 抽象一个稳定的网络访问地址
    • 一个Service可以看作一组提供相同服务的Pod的对外访问接口，作用于哪些Pod是通过标签选择器来定义的

   

  • Label

    • K8S提供了一种机制来为Pod进行分类，那就是Label（标签），同一类pod会拥有相同的标签

    • Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改

    • 给某个资源对象定义一个Label，就相当于给它打了一个标签，可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，K8S通过这种方式实现了类似SQL的对象查询机制

    • 应用场景

      • 未使用前，分散难管理，如果需要部署不同版本的应用到不同的环境中，难操作

      

      • 为Pod打上不同标签，使用Label组织的Pod，轻松管理

      

  • Label选择器

    • 对应的资源打上标签后,可以使用标签选择器过滤指定的标签

    • 标签选择器目前有两个

      • 基于等值关系(等于、不等于)
      • 基于集合关系(属于、不属于、存在)

       

  • NameSpace：

    • 可以在一个物理集群上运行多个虚拟集群，这种虚拟集群被称作 命名空间，用来隔离pod的运行环境

    • 同一个名字空间中的资源名称必须唯一，而不同名字空间之间则没有这个要求

    • NameSpace是不能嵌套的，每一个 Kubernetes 的资源都只能在一个NameSpace内

    • 名字空间是在多个用户之间划分集群资源的一种方法（通过资源配额）

    • 不必使用多个名字空间来分隔轻微不同的资源，例如同一软件的不同版本： 应该使用标签 来区分同一名字空间中的不同资源

    • Kubernetes 会创建四个初始NameSpace名称空间：

      • default 没有指明使用其它名字空间的对象所使用的默认名字空间
      • kube-system Kubernetes 系统创建对象所使用的名字空间
      • kube-public
      • kube-node-lease

• 应用分类

  • 有状态应用

    • 不能简单的实现负载均衡的服务，有数据产生的服务，Redis、MySql、RabbitMQ等
    • 相关服务须通过一些较复杂的配置才能做到负载均衡。
    • 有状态的应用，建议直接在物理机部署，方便维护管理

  • 无状态应用

    • 没有对应业务数据的应用，可以简单的实现负载均衡，复制一个节点即可快速扩容，如SpringCloud中的业务服务
    • 无状态的应用适合部署在 Kubernetes（K8s）中或者容器中。

第4集 Kubernetes常见概念组件和整体架构讲解《下》

• 简介：Kubernetes常见组件和整体架构讲解《下》

• K8S整体架构，也是Client-Server模型

  • 控制节点Master-Node，负责集群的管理

    • apiserver：提供操作【k8s集群资源】的唯一入口，RESTful方式请求,并提供认证、授权、访问控制、API注册和发现等
    • scheduler：负责资源的调度，按照预定的调度策略，【计算】将Pod调度到相应的Node节点进行应用部署
    • controller-manager：控制器管理中心，负责维护集群的状态，比如故障检测、滚动更新等，根据调度器的安排通知对应的节点创建pod
    • etcd：存储中心，是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库

     

  • 工作节点Worker-Node，负责为集群提供运行环境

    • Node是Pod真正运行的主机，可以是物理机也可以是虚拟机, Node本质上不是K8S来创建的， K8S只是管理Node上的资源，为了管理Pod，每个Node节点上至少需要运行container runtime（Docker）、kubelet和kube-proxy服务
    • kubelet：相当于主节点派到工作节点的一个代表，用于管理本机容器（相当于master节点的化身），负责维护容器的生命周期也负责Volume(CVI)和网络（CNI）的管理
    • kube-proxy：负责为Service提供cluster内部的服务发现/网络代理/负载均衡等操作，为部署的应用程序提供访问入口，和apiserver是不一样的，后者是操作k8s集群内部的

• 架构图

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第三章 K8S常见集群架构和云服务器搭建实战

第1集 K8S常见集群架构和搭建方式介绍

简介：K8S常见集群架构和搭建方式介绍

• k8s集群类型有多种

  • 单master-Node集群

    • 一主多从，推荐测试环境
    • 服务器要求：服务器要求至少2台2核4G以上的云服务器

  • 多master-Node集群

    • 多主多从（高可用集群），推荐生产环境使用
    • 服务器要求：服务器要求至少4台2核4G以上的云服务器

  • 单节点k8s集群

    • 单一个节点
    • 服务器要求：服务器要求至少一台2核4G以上的云服务器

  

• k8s搭建方式：

  • kubeadm搭建（推荐）

    • 是一个K8s部署工具，提供kubeadm init和kubeadm join
    • 用于快速搭建k8s集群，比较推荐

  • 二进制包搭建

    • 从github下载发行版的二进制包，手动部署每个组件， 组成Kubernetes集群
    • 可以了解底层，但是步骤繁琐，坑比较多

  • Minikube搭建：

    • 是一种轻量化的Kubernetes集群，是k8s社区为了帮助开发者和学习者能够更好学习和体验k8s功能而推出的，使用个人PC的虚拟化环境就快速构建启动单节点k8s

     

• 课程选择方案

  • 方案一：Minikube搭建进行搭建，1台服务器

  • 方案二：一主多从，共2台以上服务器

  • 多种方案都可以，所以搭建不用纠结学习使用哪种，命令操作都一样的

  • 每台机器配置需要 2核4G内存以上

     

   

• 云服务器说明【！！！！特别重要！！！！】

  • 本地虚拟机或者其他系统，存在各种系统版本、内核参数调整、swap分区、网络问题等
  • 每一个问题都可以都可以卡不少时间，浪费没必要的精力【本来3天的内容，愣是环境1周都没搭建好】
  • 避免这些兼容性问题：统一使用阿里云Linux CentOS 7.8
  • 如果多节点集群搭建，可以使用阿里云的按量付费选择多台ECS服务器即可

• 如果不会阿里云服务器，进入小滴课堂官网搜索【环境安装】学习

第2集 基于Minikube搭建单节点 k8s集群

简介：急速上手Minikube搭建单节点 k8s集群实战

• Minikube搭建：

  • 是一种轻量化的Kubernetes集群，是k8s社区为了帮助开发者和学习者能够更好学习和体验k8s功能而推出的，使用个人PC的虚拟化环境就快速构建启动单节点k8s
  • 机器准备：阿里云 CentOS 7.x ，2核4g

• 安装

  • 安装Docker

  ​x
  # 1.先安装yml
  yum install -y yum-utils device-mapper-persistent-data lvm2
  # 2.设置阿里云镜像
  sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
  
  # 3.查看可安装的docker版本
  yum list docker-ce --showduplicates | sort -r
  
  #4. 安装docker
  yum -y install docker-ce-20.10.10-3.el7
  
  #5. 查看docker版本
  docker -v
  
  #配置开机自启动
  systemctl enable docker.service
  
  #6. 启动docker
  systemctl start docker
  
  
  #7. 查看docker 启动状态
  systemctl status docker
  

  • 配置镜像源

  xxxxxxxxxx
  cat > /etc/yum.repos.d/kubernetes.repo << EOF
  [kubernetes]
  name=Kubernetes
  baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
  enabled=1
  gpgcheck=0
  repo_gpgcheck=0
  gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
  EOF
  

  • 安装kubectl

  xxxxxxxxxx
  yum install -y kubectl-1.18.0
  

  • 安装minikube

  xxxxxxxxxx
  curl -LO https://storage.googleapis.com/minikube/releases/v1.18.1/minikube-linux-amd64 && sudo install minikube-linux-amd64 /usr/local/bin/minikube
  

  • 检查minikube安装是否成功

  xxxxxxxxxx
  minikube  version
  

  • 启动minikube

  xxxxxxxxxx
  minikube start --image-mirror-country='cn'  --driver=docker --force --kubernetes-version=1.18.1 --registry-mirror=https://registry.docker-cn.com
  
  #查看
  kubectl cluster-info
  

   

   

第3集 带你5分钟基于K8S单节点部署你的第一个K8S应用

简介：5分钟带你搭建 k8s部署第一个应用

• 查看k8s集群信息

xxxxxxxxxx
kubectl cluster-info

• 查看节点信息

xxxxxxxxxx
kubectl get node

• 查看内部组件

xxxxxxxxxx
kubectl get pod -A

• 部署第一个K8S应用-Nginx，并通过公网ip访问

  • 创建deployment（Pod控制器的一种, 直接删除pod后，会自动创建新的，需要删除deployment）

  xxxxxxxxxx
  kubectl create deployment xdclass-nginx --image=nginx:1.23.0
  
  对比Docker部署
    docker run  --name xdclass-nginx -p 8080:80 -d nginx:1.23.0
  

  • 查看deployment和pod

  xxxxxxxxxx
  kubectl get deployment,pod,svc
  

  

  • 暴露80端口, 就是service服务

  xxxxxxxxxx
  kubectl expose deployment xdclass-nginx --port=80  --type=NodePort
  

  • 转发端口（Mini Kube临时）

  xxxxxxxxxx
  kubectl port-forward  --address 0.0.0.0   service/xdclass-nginx 80:80
  
  解释：
    kubectl port-forward 转发一个本地端口到 Pod 端口，不会返回数据，需要打开另一个终端来继续这个练习
  

  • 在浏览器访问公网ip（网络安全组记得开放80端口）

  

• 注意

  • Minikube的搭建跟用Kubeadm的有一点不一样

    • Nodeport不能通过ip+端口直接访问，要通过minikube service(内网访问)和端口转发（公网访问）

第4集 基于KubeAdm搭建多节点K8S集群

简介：基于KubeAdm搭建多节点K8S集群

• 安装步骤

  • 安装docker（主节点+工作节点）

    xxxxxxxxxx
    # 1.先安装yml
    yum install -y yum-utils device-mapper-persistent-data lvm2
    # 2.设置阿里云镜像
    sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
    
    # 3.查看可安装的docker版本
    yum list docker-ce --showduplicates | sort -r
    
    #4. 安装docker
    yum -y install docker-ce-20.10.10-3.el7
    
    #5. 查看docker版本
    docker -v
    
    #配置开机自启动
    systemctl enable docker.service
    
    #6. 启动docker
    systemctl start docker
    
    #7. 查看docker 启动状态
    systemctl status docker
    

  • 配置阿里云镜像源（主节点+工作节点）

    xxxxxxxxxx
    cat > /etc/yum.repos.d/kubernetes.repo << EOF
    [kubernetes]
    name=Kubernetes
    baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
    enabled=1
    gpgcheck=0
    repo_gpgcheck=0
    gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
    EOF
    

  • 安装kubelet kubeadm kubectl（主节点+工作节点）

    xxxxxxxxxx
    yum install -y kubelet-1.18.0 kubeadm-1.18.0 kubectl-1.18.0
    

  • 主节点初始化（主节点）

    xxxxxxxxxx
    kubeadm init \
    --apiserver-advertise-address=172.31.101.9 \
    --image-repository registry.aliyuncs.com/google_containers \
    --kubernetes-version v1.18.0 \
    --service-cidr=10.96.0.0/12 \
    --pod-network-cidr=10.244.0.0/16
    
    只修改两个地方(master主机【内网IP】，k8s软件版本)
    

    • 说明：

      • --apiserver-advertise-address：主节点的内网ip地址
      • --image-repository 镜像仓库
      • --kubernetes-version k8s版本
      • --service-cidr + --pod-network-cidr 网段不重复即可

  • 当初始化完成之后执行命令，并加入工作节点

  

  • 主节点执行命令

  

  • 加入工作节点

    

  • 查看节点

    xxxxxxxxxx
    kubectl get nodes
    
    #状态都是NotReady，需要配置网络插件
    

     

  • 安装网络插件

    • 使用这个（官方改了源，直接使用这个命令）

    xxxxxxxxxx
    kubectl apply -f  https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
    

    • 下面的有问题（视频使用这个方式， 官方改了源，不可用，采用上面的命令即可）

    xxxxxxxxxx
    kubectl apply -f flannel.yaml 
    
    #flannel.yaml 文件内容
    ---
    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: psp.flannel.unprivileged
      annotations:
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
        seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
        apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
        apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
    spec:
      privileged: false
      volumes:
        - configMap
        - secret
        - emptyDir
        - hostPath
      allowedHostPaths:
        - pathPrefix: "/etc/cni/net.d"
        - pathPrefix: "/etc/kube-flannel"
        - pathPrefix: "/run/flannel"
      readOnlyRootFilesystem: false
      # Users and groups
      runAsUser:
        rule: RunAsAny
      supplementalGroups:
        rule: RunAsAny
      fsGroup:
        rule: RunAsAny
      # Privilege Escalation
      allowPrivilegeEscalation: false
      defaultAllowPrivilegeEscalation: false
      # Capabilities
      allowedCapabilities: ['NET_ADMIN']
      defaultAddCapabilities: []
      requiredDropCapabilities: []
      # Host namespaces
      hostPID: false
      hostIPC: false
      hostNetwork: true
      hostPorts:
      - min: 0
        max: 65535
      # SELinux
      seLinux:
        # SELinux is unsed in CaaSP
        rule: 'RunAsAny'
    ---
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: flannel
    rules:
      - apiGroups: ['extensions']
        resources: ['podsecuritypolicies']
        verbs: ['use']
        resourceNames: ['psp.flannel.unprivileged']
      - apiGroups:
          - ""
        resources:
          - pods
        verbs:
          - get
      - apiGroups:
          - ""
        resources:
          - nodes
        verbs:
          - list
          - watch
      - apiGroups:
          - ""
        resources:
          - nodes/status
        verbs:
          - patch
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: flannel
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: flannel
    subjects:
    - kind: ServiceAccount
      name: flannel
      namespace: kube-system
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: flannel
      namespace: kube-system
    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: kube-flannel-cfg
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    data:
      cni-conf.json: |
        {
          "cniVersion": "0.2.0",
          "name": "cbr0",
          "plugins": [
            {
              "type": "flannel",
              "delegate": {
                "hairpinMode": true,
                "isDefaultGateway": true
              }
            },
            {
              "type": "portmap",
              "capabilities": {
                "portMappings": true
              }
            }
          ]
        }
      net-conf.json: |
        {
          "Network": "10.244.0.0/16",
          "Backend": {
            "Type": "vxlan"
          }
        }
    ---
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: kube-flannel-ds-amd64
      namespace: kube-system
      labels:
        tier: node
        app: flannel
    spec:
      selector:
        matchLabels:
          app: flannel
      template:
        metadata:
          labels:
            tier: node
            app: flannel
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: beta.kubernetes.io/os
                        operator: In
                        values:
                          - linux
                      - key: beta.kubernetes.io/arch
                        operator: In
                        values:
                          - amd64
          hostNetwork: true
          tolerations:
          - operator: Exists
            effect: NoSchedule
          serviceAccountName: flannel
          initContainers:
          - name: install-cni
            image: lizhenliang/flannel:v0.11.0-amd64 
            command:
            - cp
            args:
            - -f
            - /etc/kube-flannel/cni-conf.json
            - /etc/cni/net.d/10-flannel.conflist
            volumeMounts:
            - name: cni
              mountPath: /etc/cni/net.d
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          containers:
          - name: kube-flannel
            image: lizhenliang/flannel:v0.11.0-amd64 
            command:
            - /opt/bin/flanneld
            args:
            - --ip-masq
            - --kube-subnet-mgr
            resources:
              requests:
                cpu: "100m"
                memory: "50Mi"
              limits:
                cpu: "100m"
                memory: "50Mi"
            securityContext:
              privileged: false
              capabilities:
                 add: ["NET_ADMIN"]
            env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            volumeMounts:
            - name: run
              mountPath: /run/flannel
            - name: flannel-cfg
              mountPath: /etc/kube-flannel/
          volumes:
            - name: run
              hostPath:
                path: /run/flannel
            - name: cni
              hostPath:
                path: /etc/cni/net.d
            - name: flannel-cfg
              configMap:
                name: kube-flannel-cfg
    

  • 查看节点状态

    xxxxxxxxxx
    kubectl get node
    

  • 查看系统pod状态

    xxxxxxxxxx
    kubectl get pods -n kube-system
    

     

第5集 带你5分钟基于K8S集群部署你的第一个K8S应用

简介： 带你5分钟基于K8S集群部署你的第一个K8S应用

• 查看k8s集群信息

xxxxxxxxxx
kubectl cluster-info

• 查看节点信息

xxxxxxxxxx
kubectl get node

• 查看内部组件

xxxxxxxxxx
kubectl get pod -A

• 部署第一个K8S应用-Nginx，并通过公网ip访问

  • 创建deployment（Pod控制器的一种）

  xxxxxxxxxx
  kubectl create deployment xdclass-nginx --image=nginx:1.23.0
  

  • 查看deployment和pod

  xxxxxxxxxx
  kubectl get deployment,pod,svc
  

  

  • 暴露80端口，创建service

  xxxxxxxxxx
  kubectl expose deployment xdclass-nginx --port=80 --type=NodePort
  

  • 查看端口映射

  xxxxxxxxxx
  kubectl get pod,svc
  

  

  • 在浏览器访问, 工作节点开放端口31512，访问工作节点ip：31512（网络安全组记得开放31512端口）

    • master、node节点访问这个 开放的端口都可以

    

    

    

   

• 注意

  • Minikube的搭建跟用Kubeadm的有一点不一样
  • Kubeadm部署，暴露端口对外服务，会随机选端口，默认范围是30000~32767，可以修改指定，后续会讲

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第四章 Kubernetes核心资源管理操作实战

第1集 Kubernetes常见资源管理命令介绍

简介：Kubernetes常见资源管理命令介绍

• 概念

  • k8s是一个服务器集群系统，用户可以在集群中部署各种服务，也就是在k8s集群上运行一个个的容器
  • 在k8s中，pod是最小的管理单元而非容器，一个pod中可以有多个容器
  • 在k8s集群中，所有内容都可以被抽象为资源，通过操作资源来管理k8s集群

   

• 使用kubectl来管理资源

  • kubectl用法：

    xxxxxxxxxx
    kubectl [command] [TYPE] [NAME] [flags]
    

    • commad：对资源具体的操作，如create创建、 get获取 、 delete删除
    • TYPE:指定资源类型，大小写敏感
    • NAME：指定资源的名称，大小写敏感，如果省略名称则显示所有资源
    • flags：指定可选的参数，如可用-s或者-server指定Kubernetes API server的地址和端口

     

  • 例子

    xxxxxxxxxx
    #获取全部节点
    kubectl get node
    
    #获取全部pod
    kubectl get pod
    
    #查看某个pod内容
    kubectl get pod pod_name
    
    #获取全部名称空间
    kubectl get ns
    
    
    #查看创建的资源
    kubectl get pod,svc,deploy
    
    # 删除nginx pod，如果是靠deploy控制器创建的pod, 直接删除则会自动创建新的；
    kubectl delete pod pod名称
    
    # 如果需要删除则直接删除depoly控制器即可，pod会被删除
    

  • 资源管理方式：

    • 命令式对象管理：直接使用命令去操作资源

      xxxxxxxxxx
      kubectl run 资源名称 --image=镜像名称 --port=端口号
      
      例子：
        kubectl run xdclass-nignx-pod --image=nginx:1.23.0 --port=80
        kubectl create deployment xdclass-nginx --image=nginx:1.23.0
      

    • 命令式对象配置：通过命令配置和配置文件去操作资源

      xxxxxxxxxx
      kubectl create -f 配置文件名称.yaml
      

    • 声明式对象配置：通过apply和配置文件操作资源

      xxxxxxxxxx
      kubectl apply -f 配置文件名称.yaml
      

• yaml例子

  xxxxxxxxxx
  apiVersion: apps/v1
  kind: Deployment
  metadata:
     name: nginx-deployment
     labels:
        app: nginx-deployment
  spec:
     replicas: 1
     selector:
        matchLabels:
           app: nginx-pod
     template:
        metadata:
             labels:
                app: nginx-pod
        spec:
           containers:
           - name: nginx
               image: nginx:1.23.0
               imagePullPolicy: IfNotPresent
               ports:
               - containerPort: 80
  

  xxxxxxxxxx
  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
  spec:
    containers:
    - image: nginx:1.23.0
      name: pod
      ports:
      - name: nginx-port
        containerPort: 80
        protocol: TCP
  

   

• kubectl create 和 kubectl apply的区别：

  • kubectl create 命令首次执行时会创建资源，当再次执行的时候会报错，因为资源名称在同一命名空间内是唯一的
  • kubectl apply在首次执行的时候也会创建对应的资源，当再次执行的时候会根据配置文件进行升级、扩容等操作，即使配置文件没有变化也不影响

   

第2集 Kubernetes资源文件yaml参数介绍

简介：Kubernetes资源文件yaml参数介绍

• yaml介绍

  • yaml是一个类似 XML、JSON 的标记性语言。它强调以数据为中心，并不是以标识语言为重点。

  • 例如SpringBoot的配置文件application.yml也是一个yaml格式的文件

  • 语法格式：

    • 通过缩进表示层级关系
    • 不能使用tab进行缩进，只能使用空格
    • 一般开头缩进两个空格
    • 大小写敏感
    • 字符后缩进一个空格，如冒号、逗号
    • 如果需要将多段yaml配置放在一个文件中，中间要使用---分隔
    • 使用#表示注释

   

  • yaml文件的编写：

    • 不需要从零手写，快速编写yaml文件，通过命令导出新的yaml文件

      xxxxxxxxxx
      #创建nginx资源文件并且不启动资源
      kubectl create deployment xdclass-nginx --image=nginx:1.23.0 -o yaml --dry-run=client > nginx.yaml
      
      #查看nginx.yaml
      cat nginx.yaml
      

    • 精简版 yaml

      xxxxxxxxxx
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        creationTimestamp: null
        labels:
          app: xdclass-nginx
        name: xdclass-nginx
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: xdclass-nginx
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: xdclass-nginx
          spec:
            containers:
            - image: nginx:1.23.0
              name: nginx
              resources: {}
      status: {}
      

   

  • pod的yaml文件示例

    • yaml文件示例：

      xxxxxxxxxx
      # pod的最基础的yaml文件最少需要以下的几个参数
      apiVersion: v1 # API版本号，注意：具有多个，不同的对象可能会使用不同API
      kind: Pod  # 对象类型，pod
      metadata:  # 元数据
        name: string # POD名称
        namespace: string # 所属的命名空间
      spec: # specification of the resource content(资源内容的规范)
        containers: # 容器列表
          - name: string # 容器名称
            image: string # 容器镜像
      

  • 常用字段含义

    • 必须存在的属性

      参数名	字段类型	说明
      version	String	k8s API的版本，可使用kubectl api-versions命令查询
      kind	String	这里指定k8s资源的类型，比如Pod、Deployment
      metadata	Object	元数据对象，固定写值metadata
      metadata-name	String	元数据对象的名字，比如命名pod的名字
      metadata-namespace	String	元数据对象的命名空间
      spec	Object	详细定义对象，固定值写Spec
      spec.container[]	list	spec对象的容器列表定义
      spec.container[].name	String	容器对象的名字
      spec.container[].image	String	定义要用到的对象名称

       

    • spec主要对象【大体知道即可】

      • spec.containers

      参数名	字段类型	说明
      spec.containers[].name	String	定义容器的名字
      spec.containers[].image	String	定义要用到的镜像名称
      spec.containers[].imagePullPolicy	String	定义镜像拉取策略，有Always、Never、IfNotPresent三个值可选（1）Always：意思是每次都尝试重新拉取镜像 （2）Never：表示仅使用本地镜像 （3）IfNotPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。 上面三个值都没设置的话，默认是Always。
      spec.containers[].command[]	List	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
      spec.containers[].args[]	List	指定容器启动命令参数，因为是数组可以指定多个。
      spec.containers[].workingDir	String	指定容器的工作目录
      spec.containers[].volumeMounts[]	List	指定容器内部的存储卷配置
      spec.containers[].volumeMounts[].name	String	指定可以被容器挂载的存储卷的名称
      spec.containers[].volumeMounts[].mountPath	String	指定可以被容器挂载的存储卷的路径
      spec.containers[].volumeMounts[].readOnly	String	设置存储卷路径的读写模式，ture 或者false，默认为读写模式
      spec.containers[].ports[]	List	指定容器需要用到的端口列表
      spec.containers[].ports[].name	String	指定端口名称
      spec.containers[].ports[].containerPort	String	指定容器需要监听的端口号
      spec.containers[].ports[].hostPort	String	指定容器所在主机需要监听的端口号，默认跟上面containerPort相同，注意设置了hostPort 同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）
      spec.containers[].ports[].protocol	String	指定端口协议，支持TCP和UDP，默认值为TCP
      spec.containers[].env[]	List	指定容器运行前需设置的环境变量列表
      spec.containers[].env[].name	String	指定环境变量名称
      spec.containers[].env[].value	String	指定环境变量值
      spec.containers[].resources	Object	指定资源限制和资源请求的值（这里开始就是设置容器的资源上限）
      spec.containers[].resources.limits	Object	指定设置容器运行时资源的运行上限
      spec.containers[].resources.limits.cpu	String	指定CPU的限制，单位为core数，将用于 docker run --cpu-shares参数（这里前面文章Pod资源限制有讲过）
      spec.containers[].resources.limits.memory	String	指定MEM内存的限制，单位为MIB、GiB
      spec.containers[].resources.requests	Object	指定容器启动和调度时的限制设置
      spec.containers[].resources.requests.cpu	String	CPU请求，单位为core数，容器启动时初始化可用数量
      spec.containers[].resources.requests.memory	String	内存请求，单位为MIB、GiB，容器启动的初始化可用数量

      • spec.volumes

      参数名	字段类型	说明
      spec.volumes[].name	String	定义Pod的共享存储卷的名称，容器定义部分的spec.containers[].volumeMounts[].name的值跟这里是一样的。
      spec.volumes[].emptyDir	Object	指定Pod的临时目录，值为一个空对象：emptyDir:{}
      spec.volumes[].hostPath	Object	指定挂载Pod所在宿主机的目录
      spec.volumes[].hostPath.path	String	指定Pod所在主机的目录，将被用于容器中mount的目录
      spec.volumes[].secret	Object	指定类型为secret的存储卷，secret意为私密、秘密的意思，很容易理解，它存储一些密码，token或者秘钥等敏感安全文件。挂载集群预定义的secret对象到容器内部。
      spec.volumes[].configMap	Object	指定类型为configMap的存储卷，表示挂载集群预定义的configMap对象到容器内部。
      spec.volumes[].livenessProbe	Object	指定Pod内容器健康检查的设置，当探测无响应几次后，系统将自动重启该容器。这个在前面的文章中有说，具体可以设置：exec、httpGet、tcpSocket。
      spec.volumes[].livenessProbe.exec	Object	指定Pod内容器健康检查的设置，确定是exec方式
      spec.volumes[].livenessProbe.exec.command[]	String	指定exec方式后需要指定命令或者脚本，用这个参数设置
      spec.volumes[].livenessProbe.httpGet	Object	指定Pod内容器健康检查的设置，确定是httpGet方式
      spec.volumes[].livenessProbe.tcpSocket	Object	指定Pod内容器健康检查的设置，确定是tcpSocket方式
      spec.volumes[].livenessProbe.initialDelaySeconds	Number	容器启动完成后手册探测的时间设置，单位为s
      spec.volumes[].livenessProbe.timeoutSeconds	Number	对容器健康检查的探测等待响应的超时时间设置，单位为S，默认为1s。若超过该超时时间设置，则认为该容器不健康，会重启该容器。
      spec.volumes[].livenessProbe.periodSeconds	Number	对容器健康检查的定期探测时间设置，单位为S，默认10s探测一次。

       

第3集 Kubernetes常见资源类型和命令速览

简介：Kubernetes常见资源类型和缩写

• 查看资源类型和命令

xxxxxxxxxx
#查看资源
kubectl api-resources

#查看命令帮助
kubectl --help

• 常用资源分类和缩写

  • 节点 nodes ，缩写 no

  • 名称空间 namespaces，缩写ns

  • pod资源 pods, 缩写 po

  • pod控制器

    • replicasets，缩写rs
    • deployments，缩写 deploy

  • 服务发现

    • 统一pod对外接口 services ，缩写 svc
    • 统一pod对外接口ingress ，缩写 ing

  • 存储资源

    • persistentvolumes，缩写pv
    • persistentvolumeclaims，缩写pvc

• 常用资源操作命令

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第五章 Kubernetes核心资源之名称空间和Pod实战

第1集 Kubernetes名称空间介绍和资源操作实战

简介：Kubernetes名称空间介绍和资源操作实战

• 什么是名称空间Namespace

  • Namespace是k8s系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多用户的资源隔离。
  • 默认情况下，k8s集群中的所有的Pod都是可以相互访问的。
  • 但是在实际中，可能不想让两个Pod之间进行互相的访问，那此时就可以将两个Pod划分到不同的namespace下。
  • k8s通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的"组"，以方便不同的组的资源进行隔离使用和管理。
  • 可以通过k8s的授权机制，将不同的namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。
  • 结合k8s的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。

   

• Kubernetes 会创建四个初始NameSpace名称空间：

  • default

    • 没有指明使用其它名字空间的对象所使用的默认名字空间

  • kube-system

    • Kubernetes 系统创建对象所使用的名字空间

  • kube-public

    • 是自动创建的，命名空间下的资源可以被所有人访问（包括未认证用户）

  • kube-node-lease

    • 集群节点之间的心跳维护

• 查看所有命令空间

  xxxxxxxxxx
  kubectl get namespace
  缩写
    kubectl get ns
  

  

• 命名空间操作

  xxxxxxxxxx
  # 创建新命名空间
    kubectl create ns dev
  
  # 查看命名空间详情  
    kubectl describe ns dev
  
  # 指定输出格式  命令：kubectl get ns ns名称  -o 格式参数, 常见的是wide、json、yaml
  # 输出命名空间详细信息
    kubectl get ns dev -o yaml
    
  # 删除命名空间
    kubectl delete ns dev
    
  # 基于配置文件方式 namespace-dev.yaml
    
  apiVersion: v1
  kind: Namespace
  metadata:
    name: dev
  
  创建：kubectl create -f namespace-dev.yaml
  
  创建：kubectl apply -f namespace-dev.yaml
  
  删除：kubectl delete -f namespace-dev.yaml
  

   

第2集 Kubernetes的Pod资源讲解实战

简介：K8S中最小的单位Pod资源讲解实战

• Pod

  • Pod是一组容器, 在K8S中，最小的单位是Pod, 一个Pod可以包含多个容器，但通常情况下我们在每个Pod中仅使用一个容器，可以把Pod理解成豌豆荚, Pod内的每个容器是一颗颗豌豆

  • Pod 的核心是运行容器，必须指定容器引擎，比如 Docker是其中一种技术

  • 分类

    • 自主创建：直接创建出来的Pod，这种pod删除后就没有了，也不会自动重建
    • 控制器创建：通过控制器创建的pod，这类Pod删除了之后还会自动重建

    

  • Pod运行容器数量

    • 每个Pod中一个容器，的模式是最常见的用法，Pod是容器的简单封装，K8S管理Pod而不是直接管理容器
    • 一个Pod中同时运行多个需要互相协作的容器，它们共享资源，同一个Pod中的容器可以作为service单位

• Pod网络

  • 一个 pod 包含一组容器，一个 pod 不会跨越多个工作节点
  • 每个Pod都会被分配一个唯一的IP地址，Pod中的所 有容器共享网络空间，包括IP地址和端口
  • Pod内 部的容器可以使用localhost互相通信

  

• Pod存储

  • Volume 也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失
  • Pod中 的所有容器都可以访问共享的Volume

   

• K8S集群中的系统组件都是以Pod方式运行的

  xxxxxxxxxx
  kubectl get pod -n kube-system
  

   

• 命令

  xxxxxxxxxx
  #查看创建的资源
  kubectl get pod,deploy 
  
  # 删除nginx pod，如果是靠deploy控制器创建的pod, 直接删除则会自动创建新的；
  kubectl delete pod pod名称 -n 名称空间
  
  #通过控制器创建pod，则删除控制器即可
  kubectl delete pod控制器名称 -n 名称空间
  
  
  # 运行pod，指定名称空间
  kubectl run xdclass-nignx-pod --image=nginx:1.23.0 --port=80 --namespace dev
  
  # 通过 deployment控制器导出yaml文件，指定名称空间
  kubectl create deployment xdclass-nginx --image=nginx:1.23.0 --namespace dev -o yaml --dry-run=client > nginx.yaml
  
  #一次性部署3个pod,修改nginx.yaml 下面的从 1 改为 3
  #使用 kubectl apply -f nignx.yaml
  spec:
    replicas: 3
  

  

• 访问

  xxxxxxxxxx
  #查看某个名称空间下 pod 更多信息
  kubectl get pod -n dev -o wide
  
  #访问pod，同个集群下面，master和node节点都可以访问（同个K8S内部网络）
  curl 10.244.1.20
  
  #备注，如果使用了Service，即NodePort端口，开放了网络安全组则外网也可以访问
  

  

第3集 Kubernetes中Pod资源进阶底层讲解

简介：Kubernetes中Pod资源进阶底层讲解

• Pod底层原型

  • 每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类

    • 用户程序所在的容器，数量可多可少

    • Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：

      • 以它为依据，评估整个Pod的健康状态

      • 可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信

      • 实现机制

        • 通过共享网络

          • 通过pause容器，把其他业务容器加入到pause容器里面，让所有业务容器在同一个namespace中，可以实现网络共享

        • 通过共享存储

          • 引入数据卷volume的概念，使用数据卷进行持久化存储

  

• pod镜像拉取策略imagesPullPolicy

  • IfNotPresent:默认值，镜像在宿主机上不存在时才拉取

xxxxxxxxxx
- Always:每次创建pod都会重新拉取一次镜像

xxxxxxxxxx
- Never:pod永远不会主动拉取这个镜像

• pod资源限制

  • 说明：

    • requests: 资源请求量，当容器运行时，向Node申请的最少保障资源
    • limits: 资源上限，容器在Node上所能消耗的最高上限

  xxxxxxxxxx
  resources：
    requests：
      memory："内存大小"
      cpu："cpu占用大小"
    limits: 
      memory："内存占用大小"
      cpu："cpu占用大小"
      
  ——————————————————————————————————————————————
  CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：
  1 个 AWS vCPU
  1 个 Azure vCore
  
  例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同
  
  文档地址:
  https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/
  

  

• pod的创建流程

  • 通过kubectl apply -f xxx.yaml 创建pod
  • 创建pod的时候：

  xxxxxxxxxx
  - kubectl向apiserver发送创建pod的请求 
  
  - apiserver把pod的创建信息存储到etcd进行保存
  
  - scheduler监听到未绑定node的pod资源，通过调度算法对该pod资源选定一个合适的node进行绑定，然后响应给apiserver，更新pod状态并存储到etcd中
  
  - 在绑定的node中，Controller-Manager通知kubelet收到分配到自身节点上的pod，调用容器引擎api创建容器，并把容器状态响应给apiserver
  

   

   

  

• Pod的调度策略

  • 在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解k8s对Pod的调度规则

  • 影响pod调度的因素：

    • pod资源限制：scheduler根据requests找到足够大小的node进行调度

    • 节点选择器标签（nodeSelector）

      • 把节点进行区分，例如dev开发环境和prod生产环境
      • 例如，当前需要把pod调度到开发环境中，则可以通过scheduler将pod调度到标签选择器中为env_role:dev的node中

      xxxxxxxxxx
      nodeSelector: 
        env_role:dev/prod
      

  

第4集 Kubernetes标签Label和标签选择器实战

简介：Kubernetes标签Label和标签选择器实战

• Label

  • K8S提供了一种机制来为资源进行分类，那就是Label（标签），同一类资源会拥有相同的标签

  • 具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改

  • 可以附加到各种资源对象上，如Node,Pod,Service,RC等,一个资源拥有多个标签，可以实现不同维度的管理

  • 给某个资源对象定义一个Label，就相当于给它打了一个标签，可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，K8S通过这种方式实现了类似SQL的对象查询机制

  • 每个资源都存在多维度属性

    xxxxxxxxxx
    版本标签："release" : "stable" , "release" : "canary"...
    
    环境标签："environment" : "dev" , "environment" : "production"
    
    架构标签："tier" : "frontend" , "tier" : "backend" , "tier" : "middleware"
    
    分区标签："partition" : "customerA" , "partition" : "customerB"...
    

     

  • 应用场景

    • 未使用前，分散难管理，如果需要部署不同版本的应用到不同的环境中，难操作

    

    • 为Pod打上不同标签，使用Label组织的Pod，轻松管理

    

• 标签选择器Label selector

  • 是Kubernetes核心的分组机制，通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象

  • 对应的资源打上标签后,可以使用标签选择器过滤指定的标签

  • 标签选择器目前有两个

    • matchLabels 用于定义一组Label , 基于等值关系(等于、不等于) ，类似于ＳＱＬ语句中的＝或！＝

    • matchExpressions 基于集合关系(属于、不属于、存在) ，类似于SQL语句中的in或 not in

    • 备注

      • 如果同时设置了matchLabels和matchExpressions，则两组条件为 AND关系
      • 即需要同时满足所有条件才能完成Selector的筛选

• 操作

xxxxxxxxxx
# 通过 deployment控制器导出yaml文件，指定名称空间
kubectl create deployment xdclass-nginx --image=nginx:1.23.0 --namespace dev -o yaml --dry-run=client > nginx.yaml


#命令默认不会列出任何标签
kubectl get pods 

# 使用 --show-labels 选项来查看
kubectl get pod -n dev --show-labels 

# 查看 deploy控制器标签
kubectl get deploy -n dev --show-labels

# 查看 pod 标签
kubectl get pod -n dev --show-labels
# 查看node节点标签
kubectl get node  --show-labels

#给Pod资源打标签
kubectl label pod pod名称 -n dev version=1.0

例子：kubectl label pod xdclass-nginx-859bdb9994-kglj8 -n dev version=1.0


#给Pod资源更新标签
kubectl label pod pod名称 -n dev version=2.0 --overwrite
例子：kubectl label pod xdclass-nginx-859bdb9994-kglj8 -n dev version=2.0 --overwrite

#使用标签选择器
kubectl get pod -l "version=2.0" -n dev --show-labels
kubectl get pod -l "version!=2.0" -n dev --show-labels


#删除标签 语法 kubectl label pod pod名称 -n dev 标签名-
kubectl label pod pod名称 -n dev version-
例子
  kubectl label pod xdclass-nginx-859bdb9994-kglj8 -n dev version-

• 配置查看案例

xxxxxxxxxx
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: xdclass-nginx
  name: xdclass-nginx
  namespace: dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: xdclass-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: xdclass-nginx
    spec:
      containers:
      - image: nginx:1.23.0
        name: nginx
        resources: {}
status: {}

第5集 Kubernetes的NodeSelector标签选择器实战

简介：Kubernetes的NodeSelector标签选择器实战

• nodeSelector

  • 是 PodSpec 的一个字段
  • 使用NodeSelector，测试 pod 并指定 nodeSelector 选项绑定节点

  xxxxxxxxxx
  # 查看node节点标签
  kubectl get node  --show-labels
  

   

• 配置文件

  xxxxxxxxxx
  apiVersion: v1
  kind: Pod
  metadata:
    name: xdclass-nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.23.0
      imagePullPolicy: IfNotPresent
    nodeSelector:
      env: test
  

  • 使用

  xxxxxxxxxx
  #创建pod
  kubectl apply -f nginx.yaml
  
  #查看pod资源
  kubectl get pod 
  
  # 当Pod 一直处于 Pending 状态时,说明该 Pod 还未被调度到某个节点上
  # Pod 中 nodeSelector 指定了节点 Label，调度器将只考虑调度 Pod 到包含该 Label 的 Node 上
  # 当不存在符合该条件的 Node 时，Pod 将无法被调度
  
  #给Node资源打标签，不能给master打标签
  kubectl label node node名称 env=test
  
  kubectl label node izwz90pegu9budx5tk4rv0z env=test
  
  
  #删除 node的标签 kubectl label node 删除指定的labels（标签 key 接 - 号即可）
  kubectl label node node名称 env-
  
  kubectl label node izwz90pegu9budx5tk4rv0z env-
  

   

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第六章 Kubernetes核心资源之Pod控制器实战

第1集 Kubernetes的Pod的幕后老板控制器讲解

简介：Kubernetes的Pod控制器讲解实战

• Pod Controller控制器

  • 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod，相当于一个状态机，用来控制Pod的具体状态和行为。controller会自动创建相应的pod资源，并在当pod发生故障的时候按照策略进行重新编排
  • 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等
  • 通俗来说就是【幕后老板】
  • yaml文件中 kind 填写对应的类型即可

• Pod Controller的类型概述

  • ReplicaSet

    • 一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数
    • 并支持pod数量扩缩容，镜像版本升级
    • 官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性

    

  • Deployment

    • 通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署
    • 当某个应用有新版本发布时，Deployment会同时操作两个版本的ReplicaSet
    • 其内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod
    • Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象

    

  • DaemonSet

    • 在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了
    • 这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod
    • 有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来
    • 而当旧节点被删除后，它上面的 Pod也相应地会被回收掉
    • 应用场景：监控告警Agent、日志组件、监控组件等

   

  • StatefulSet

    • 像RS、Deployment、DaemonSet都是面向无状态的服务，所管理的Pod的IP、名字，启停顺序都是随机
    • StatefulSet就是有状态的集合，管理所有有状态的服务，
    • StatefulSet 中的 Pod 具有黏性的、独一无二的身份标识，重新调度后PodName和HostName不变
    • Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现
    • 分配给每个 Pod 的唯一顺序索引，Pod 的名称的形式为

    xxxxxxxxxx
    <statefulset name>-<ordinal index>
    

    • 应用场景：比如MySQL、MongoDB集群

   

   

  • Horizontal Pod Autoscaler

    • 可以基于 CPU 利用率或其他指标实现Pod水平自动扩缩
    • 被伸缩的pod需要是通过deployment或者replica set管理
    • HPA不能应用于不可伸缩的对象，如：DaemonSets
    • 由资源来决定控制器行为，控制器周期性调整目标pod的副本数量，让目标pod的实际cpu使用率符合用户指定的数值

  

  • Job

    • 普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建
    • 容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态
    • 若容器中的进程因错误而终止,则需要依据配置确定是否需要重启
    • 应用场景：批处理程序，完成后容器就退出等

     

  • Cronjob：

    • Linux 中有 cron 程序定时执行任务，K8s的 CronJob 提供了类似的功能，可以定时执行 Job
    • 创建的Pod负责周期性任务控制
    • 应用场景：执行周期性的重复任务，如备份数据、发送邮件、数据报表、报告生成等

    

• 接下去我们会挑选几个常用的进行讲解

第2集 K8S核心控制器之ReplicaSet和控制器yaml模板介绍

简介：K8S核心控制器之ReplicaSet控制器和控制器模板介绍

• 备注

  • 早期k8s没那么多控制器，使用Replication Controller 来部署、升级Pod，简称RC
  • Replica Set – 下一代Replication Controller

• ReplicaSet

  • 一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数
  • 并支持pod数量扩缩容，镜像版本升级
  • 官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性

  

• 可控制器Yaml模板介绍

xxxxxxxxxx
apiVersion: apps/v1 # 版本号
kind: ReplicaSet  #资源文件 
metadata: # 元对象信息
  name: xdclass-rs #rs控制器名称
  namespace: dev #名称空间
spec: #具体详情
  replicas: 5 #副本数量
  selector: # 选择器，指定rs控制器管理哪些pod资源
    matchLabels: # 标签匹配规则
      app: xdclass-nginx-pod #标签key是app,值是xdclass-nginx-pod
      
  template: # pod模板，当数量不满足的时候，根据下面编码创建pod副本
    metadata: # 元对象信息
      labels: # pod资源标签
        app: xdclass-nginx-pod
    spec: #具体详情
      containers: # 容器数组列表
      - name: xdclass-nginx  #容器名称
        image: nginx:1.23.0  # 镜像和版本

• 案例文件 replicaset-nginx.yaml

xxxxxxxxxx
apiVersion: apps/v1
kind: ReplicaSet   
metadata:
  name: xdclass-rs
  namespace: dev
spec:
  replicas: 5
  selector: 
    matchLabels:
      app: xdclass-nginx-pod
  template:
    metadata:
      labels:
        app: xdclass-nginx-pod
    spec:
      containers:
      - name: xdclass-nginx
        image: nginx:1.23.0

• 执行

xxxxxxxxxx
#创建
kubectl apply -f replicaset-nginx.yaml

• 其他操作

xxxxxxxxxx
#查看
kubectl get pods,deploy,replicaset -o wide -n dev

# 命令行缩容
kubectl scale rs xdclass-rs --replicas=2 -n dev

# 删除，可以直接删除rs；也可以通过yaml删除
kubectl delete -f replicaset-nginx.yaml

第3集 K8S核心控制器之Deployment控制器实战

简介：K8S核心控制器之Deployment控制器实战

• Deployment

  • 通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署
  • 当某个应用有新版本发佈时，Deployment会同时操作两个版本的ReplicaSet
  • 其内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod
  • Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象
  • 总结：Deployment、ReplicaSet、Pod三者之间是一种阶梯控制的关系

  

• 配置文件 deploy-nginx-pod.yaml

xxxxxxxxxx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: xdclass-deploy
  namespace: dev
spec:
  replicas: 5
  selector: 
    matchLabels:
      app: xdclass-nginx-pod
  template:
    metadata:
      labels:
        app: xdclass-nginx-pod
    spec:
      containers:
      - name: xdclass-nginx
        image: nginx:1.23.0

• 执行

xxxxxxxxxx
#创建
kubectl apply -f deploy-nginx-pod.yaml

# 查看deployment
kubectl get deployment -n dev

#查看
kubectl get pods,deploy,replicaset -o wide -n dev


# 删除，通过yaml删除
kubectl delete -f deploy-nginx-pod.yaml

• 检查集群中的 Deployment 时，所显示的字段有：

  • NAME 列出了集群中 Deployment 的名称。
  • READY 显示应用程序的可用的“副本”数,格式是“就绪个数/期望个数”。
  • UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
  • AVAILABLE 显示可用的副本数。
  • AGE 应用程序运行的时间。

  

第4集 Deployment控制器rollout实现滚动升级

简介：Deployment控制器rollout实现滚动升级

• Deployment控制器核心

  • 适合部署无状态的应用服务
  • 用来管理pod和replicaset
  • 上线部署、副本控制、滚动更新、回滚等功能

   

• K8S的Deployment控制器滚动升级 (金丝雀发布 or 灰度发布）

  • 对各个实例批次进行单独更新,而非同一时刻对所有实例进行全部更新，达到不中断服务的更新升级方式

  • Deployment控制器 给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)

  • Deployment更新有两种方式

    xxxxxxxxxx
    spec:
      strategy:  # 策略
        type: RollingUpdate
    

    • Recreate ： 删除全部旧的pod，然后创建新的pod

    • RollingUpdate：滚动升级更新，删除部分，更新部分，在整个更新过程中，存在两个版本的pod

      • maxUnavailable

      xxxxxxxxxx
      升级过程中不可用Pod的最大数量，默认为25%
      在滚动更新时，我们可以忍受多少个 Pod 无法提供服务
      值越小越能保证服务稳定,更新越平滑
      

      • maxSurge

      xxxxxxxxxx
      升级过程中可以超过期望的Pod的最大数量，默认为25%；
      在滚动更新时，可以有多少个额外的 Pod
      值调的越大，副本更新速度越快
      

    • 例子 deploy-rollout.yaml

      xxxxxxxxxx
      MaxUnavailable为0, 在新 Pod 启动并就绪之前，不要关闭任何旧Pod
      MaxSurge 为100%, 立即启动所有新 Pod,也就是有足够的资源希望尽快完成更新。
      
      默认两个值都是 25%
        如果更新一个 100 Pod 的 Deployment，会立刻创建 25 个新 Old，同时会关闭 25 个旧 Pod；
        每次有 Pod 启动就绪，就可以关闭旧 Pod
      

      xxxxxxxxxx
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: xdclass-deploy
        namespace: dev
      spec:
        replicas: 5
        revisionHistoryLimit: 5  #保留历史版本5个
        strategy: 
          type: RollingUpdate
        selector: 
          matchLabels:
            app: xdclass-nginx-pod
        template:
          metadata:
            labels:
              app: xdclass-nginx-pod
          spec:
            containers:
            - name: xdclass-nginx
              image: nginx:1.23.0
      

       

• 查看控制器参数

  • 可以使用describe查看

  xxxxxxxxxx
   kubectl describe deploy xdclass-deploy -n dev
  

• 滚动升级

  • 将nginx版本更新至1.15.8

  xxxxxxxxxx
  kubectl set image deployment/xdclass-deploy xdclass-nginx=nginx:1.15.8 -n dev
  
  备注
    追加 --record 以保存正在更改资源的 kubectl 命令，方便查看history版本列表修改命令
    kubectl set image deployment/xdclass-deploy xdclass-nginx=nginx:1.15.8 -n dev --record=true
    
    kubectl set image deployment/xdclass-deploy xdclass-nginx=nginx:1.23.0 -n dev --record=true
  

  • 动态查看升级过程，存在多个不同版本

  xxxxxxxxxx
  kubectl get pods -n dev -w
  

• 发布回滚

  • kubectl rollout 版本升级相关介绍

    • history 升级历史记录
    • undo 默认回滚上一版本 ，使用--to-revision回滚到指定版本
    • pause 暂停版本升级发布
    • resume 继续恢复刚暂停的版本升级
    • status 升级状态

  • 查看历史版本列表

  xxxxxxxxxx
  kubectl rollout history deployment/xdclass-deploy -n dev
  

  • 查看具体某一个历史版本信息

  xxxxxxxxxx
  kubectl rollout history deployment/xdclass-deploy -n dev --revision=2
  

  • 回滚上一版本

  xxxxxxxxxx
  kubectl rollout undo deployment/xdclass-deploy -n dev
  

  • 查看升级情况

  xxxxxxxxxx
  kubectl rollout status deployment/xdclass-deploy -n dev
  

  • 回滚指定版本

  xxxxxxxxxx
  kubectl rollout undo deployment/xdclass-deploy -n dev --to-revision=2
  

• 删除deployment

  xxxxxxxxxx
  kubectl delete -f deploy-nginx-pod.yaml
  

   

第5集 K8S核心控制器之DaemonSet控制器实战

简介：K8S核心控制器之DaemonSet控制器实战

• DaemonSet（节点级别的pod）

  • 在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了
  • 这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod
  • 有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来
  • 而当旧节点被删除后，它上面的 Pod也相应地会被回收掉
  • 应用场景：监控告警Agent、日志组件、监控组件等

• 案例 daemonset-nginx.yaml

  xxxxxxxxxx
  apiVersion: apps/v1
  kind: DaemonSet   
  metadata:
    name: xdclass-ds
    namespace: dev
  spec:
    selector: 
      matchLabels:
        app: xdclass-nginx-pod
    template:
      metadata:
        labels:
          app: xdclass-nginx-pod
      spec:
        containers:
        - name: xdclass-nginx
          image: nginx:1.23.0
          imagePullPolicy: IfNotPresent
  

• 命令验证

  xxxxxxxxxx
  #创建
  kubectl apply -f daemonset-nginx.yaml
  
  #只有一个节点,多个节点的话，每个节点都有一个pod
  kubectl get pod,deploy,rs,ds -n dev
  

第6集 K8S核心控制器之Job控制器实战

简介：K8S核心控制器之Job控制器实战

• Job控制器

  • 普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建
  • 容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态
  • 若容器中的进程因错误而终止,则需要依据配置确定是否需要重启
  • 应用场景：批处理程序，完成后容器就退出等
  • 启动pod在运行完毕任务后，就会变成Completed状态，job的状态会更新为complete，这个job任务已经执行完成，pod不在系统中继续运行

• 参数讲解

  xxxxxxxxxx
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: xdclass-job
    namespace: dev
  spec:
    parallelism: 2 #job并发运行Pods的数量，默认 1
    completions: 3 #job需要成功运行Pods的次数,默认 1
    backoffLimit: 5 #job失败后进行重试的次数，默认是6
    activeDeadlineSeconds: 100 #job运行超时时间，当job超过timeout时间，则job的状态也会更新为failed
    template:
      spec:
        restartPolicy: Never #job重启策略，OnFailure或Never 
        containers:
        - name: demo
          image: busybox:1.35.0 
          # 容器的启动命令列表,在pod中的容器初始化完毕后运行命令
          command: ["echo","hello xdclass.net k8s job"]  
  

  • BusyBox

    • 是一个集成了三百多个最常用Linux命令和工具的软件
    • 包含了简单的工具，例如ls、cat和echo等等，还包含了一些更复杂的工具，例grep、find、telnet

• 案例实战

  xxxxxxxxxx
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: xdclass-job
  spec:
    parallelism: 2
    completions: 3
    backoffLimit: 5
    activeDeadlineSeconds: 100
    template:
      spec:
        restartPolicy: Never
        containers:
        - name: demo
          image: busybox:1.35.0 
          command: ["echo","hello xdclass.net k8s job"]
  

   

  • 查看

  xxxxxxxxxx
  kubectl get job -n dev -o wide
  
  kubectl get pods -o wide
  
  #查看日志
  kubectl logs xdclass-job-75xfb
  

  

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第七章 Kubernetes核心资源之Service服务实战

第1集 带你走近K8S沐足店的Service服务

简介：带你走近K8S沐足店的服务Service

• 什么是服务service？

• Service

  • 在k8s里面，每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失，重启pod的ip地址会发生变化，此时客户如果访问原先的ip地址则会报错

  

  • Service (服务)就是用来解决这个问题的, 对外服务的统一入口，防止pod失联，定义一组pod的访问策略（服务发现、负载均衡）

  • 一个Service可以看作一组提供相同服务的Pod的对外访问接口，作用于哪些Pod是通过标签选择器来定义的

    • Service是一个概念，主要作用的是节点上的kube-proxy服务进程

  • 例子

    • 定义了3个商品微服务，由网关作为统一访问入口， 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。
    • Service 定义的抽象能够解耦这种关联。

• service分类

  • ClusterIP

    • 默认类型，自动分配一个【仅集群内部】可以访问的虚拟IP

  • NodePort

    • 对外访问应用使用，在ClusterIP基础上为Service在每台机器上绑定一个端口，就可以通过: ip+NodePort来访问该服务

  • LoadBalancer（花钱的方案）

    • 使在NodePort的基础上，借助公有云创建一个外部负载均衡器，并将请求转发到NodePort
    • 可以实现集群外部访问服务的另外一种解决方案，不过并不是所有的k8s集群都会支持，大多是在公有云托管集群中会支持该类型

  • ExternalName（很少）

    • 把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

     

• service和pod的关系

  • service和pod之间是通过 selector.app进行关联的

  xxxxxxxxxx
  spec: # 描述
    selector: # 标签选择器，确定当前service代理控制哪些pod
      app: xdclass-nginx
  

   

• yaml模板文件

xxxxxxxxxx
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: xdclass-svc
spec:
  ports:
  - port: 80  # service服务端口
    protocol: TCP
    targetPort: 80 # pod端口，常规和容器内部端口一致
  selector:
    app: xdclass-nginx-pod
status:
  loadBalancer: {}

第2集 K8S里面的多种port端口你知道怎么区分不

简介：K8S里面的port-targetPort -nodePort-containerPort 你知道怎么区分不

• 关于K8S中端口的概念区分

  • port

    • 是service端口，即k8s中服务之间的访问端口 ，clusterIP:port 是提供给集群内部客户访问service的入口

  • nodePort

    • 容器所在node节点的端口，通过nodeport类型的service暴露给集群节点，外部可以访问的端口

  • targetPort

    • 是pod的端口 ，从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上，最后进入容器。

  • containerPort

    • 是pod内部容器的端口，targetPort映射到containerPort。

  

• 总结

  • 4种端口作用不一样，port和nodePort都是service的端口
  • port暴露给集群内客户访问服务，nodePort暴露给集群外客户访问服务
  • 这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod中的容器

  xxxxxxxxxx
  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
    namespace: dev
    labels:
      app: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.20
      imagePullPolicy: IfNotPresent
      ports:
      - containerPort: 80 #容器端口 
  ---
  apiVersion: apps/v1
  kind: Service
  metadata:
    name: nginx
  spec:
    type: NodePort # 有配置NodePort，外部可访问k8s中的服务 ，
    ports:
    - name: nginx
      port: 80  # 服务service的访问端口
      protocol: TCP
      targetPort: 80  # pod端口,映射到容器端口
      nodePort: 30015  # NodePort，通过nodeport类型的service暴露给集群外部访问
    selector:
      app: nginx
  

   

第3集 K8S服务Service的ClusterIP实战

简介：K8S服务Service的ClusterIP实战

• 创建deployment

xxxxxxxxxx
kubectl apply -f deploy-nginx-pod.yaml

• 查看deployment和pod（service的缩写是svc）

xxxxxxxxxx
kubectl get deployment,pod,svc -n dev -o wide

• 暴露服务 clusterIP 类型

xxxxxxxxxx
kubectl expose deploy xdclass-deploy --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n dev

• 查看服务（多了个类型是ClusterIP的，通过curl clusterIp+port可以访问）

xxxxxxxxxx
kubectl get deployment,pod,svc -n dev -o wide

• 查看服务详情

xxxxxxxxxx
kubectl describe svc svc-nginx1 -n dev

第4集 K8S服务Service的NodePort和EndPoint实战

简介：K8S服务Service的NodePort和EndPoint实战

• NodePort

  • 常规业务的场景不全是集群内访问，也需要集群外业务访问
  • 那么ClusterIP就满足不了了，NodePort是其中的一种实现集群外部访问的方案
  • 对外访问应用使用，在ClusterIP基础上为Service在每台机器上绑定一个端口，就可以通过: ip+NodePort来访问该服务

• 创建NodePort类型服务

xxxxxxxxxx
kubectl expose deploy xdclass-deploy --name=svc-nodeport-nginx1 --type=NodePort --port=80 --target-port=80 -n dev

• 查看服务（多了个类型是NodePort的，通过curl clusterIp+port可以访问）

• 在浏览器访问, 工作节点开放端口31325，访问工作节点ip：31325（网络安全组记得开放31325端口）

  • master、node节点访问这个 开放的端口都可以

  • Kubeadm部署，暴露端口对外服务，会随机选端口，默认范围是30000~32767，可以修改指定范围

    

     

  

• 查看服务详情

xxxxxxxxxx
kubectl describe svc svc-nodeport-nginx1 -n dev

• Endpoint（缩写是ep）

  • 是k8s中的一个资源对象，存储在etcd中，记录service对应的所有pod的访问地址
  • 里面有个Endpoints列表，就是当前service可以负载到的pod服务入口
  • service和pod之间的通信是通过endpoint实现的
  • 查看endpoint列表

  xxxxxxxxxx
   kubectl get ep svc-nodeport-nginx1 -n dev -o wide
  

  

• 大家的疑惑点，service如何决定分发请求到后端的Pod？

  

  • kubernetes提供了两种负载均衡策略

    • 默认，kube-proxy的策略，如随机、轮询
    • 使用会话保持模式，即同个客户端的请求固定到某个pod，在spec中添加sessionAffinity:ClientIP即可

  • 验证

  xxxxxxxxxx
  #查看全部pod和ip
  kubectl get pods -n dev -o wide
  
  #修改pod里面容器nginx的默认静态页面,内容为Pod所在的ip
  kubectl exec -it xdclass-deploy-64967f6b67-p66wh -n dev /bin/sh
  
  echo "xdclass.net 5" > /usr/share/nginx/html/index.html
  
  # curl访问ip+port 或 浏览器直接访问
  

   

   

愿景："让编程不再难学，让技术与生活更加有趣"

更多架构课程请访问 xdclass.net

第八章 Kubernetes核心资源之数据存储持久化

第1集 K8S数据存储Volume讲解和EmptyDir实战

简介： K8S数据存储Volume讲解和EmptyDir实战

• 需求

  • 容器的生命周期可能很短，会被频繁地创建和销毁，容器 中的文件在磁盘上是临时存放的，这给容器中运行的较重要的应用程序带来一些问题

    • 问题一 ：当容器崩溃时文件丢失，kubelet 会重新启动容器，但容器会以干净的状态重启，之前保存在容器中的数据也会被清除
    • 问题二：当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件

  • Kubernetes 卷（Volume） 这一抽象概念能够解决这两个问题，卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录

  • 总结：

    • Volume是k8s抽象出来的对象，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下
    • kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储
    • Volume的生命周期不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。
    • K8S可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。

     

• Volume常见的类型：

  • 常规存储：EmptyDir、HostPath
  • 高级存储：PV、PVC
  • 配置存储：ConfigMap、Secret
  • 其他：网络存储系统 NFS、CIFS，包括云服务商提供的、本地、分布式

• EmptyDir

  • 当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，只要 Pod 在该节点上运行卷就一直存在

  • 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除

  • 容器崩溃并不会导致 Pod 被从节点上移除，所以容器崩溃时 emptyDir 卷中的数据是安全的。

  • 用途

    • 临时缓存空间

  • 案例 volume-emptydir.yaml ， pod里面定义两个容器，一个产生日志，一个是读日志输出到控制台

  

  xxxxxxxxxx
  apiVersion: v1
  kind: Pod
  metadata:
    name: xdclass-volume-emptydir
    namespace: dev
  spec:
    containers:
    - name: xdclass-nginx
      image: nginx:1.20
      ports:
      - containerPort: 80
      volumeMounts:  # 将nginx-log-volume挂在到nginx容器中，对应的目录为 /var/log/nginx
      - name: nginx-log-volume
        mountPath: /var/log/nginx
  
    - name: xdclass-busybox
      image: busybox:1.35.0 
      command: ["/bin/sh","-c","tail -f /usr/local/test/access.log"] # 容器启动后初始命令，读取指定文件中内容
      volumeMounts:  # 将nginx-log-volume挂在到busybox容器中，对应的目录为 /logs
      - name: nginx-log-volume
        mountPath: /usr/local/test
  
    volumes: # 这里声明volume存储劵， name为nginx-log-volume，类型是emptyDir
    - name: nginx-log-volume
      emptyDir: {}
  

  • 操作

  xxxxxxxxxx
  #创建
  kubectl apply -f volume-emptydir.yaml
  
  #查看
  kubectl get pods -n dev -o wide
  
  #访问nignx 产生访问日志
  curl ip
  
  #查看容器输出 -f 后是 pod的名称
  kubectl logs -f xdclass-volume-emptydir -n dev -c xdclass-busybox
  

  • 删除

  xxxxxxxxxx
  kubectl delete -f volume-emptydir.yaml
  

   

第2集 K8S数据存储Volume之hostPath实战

简介： K8S数据存储Volume之hostPath实战

• HostPath

  • emptyDir中数据没做持久化，随着Pod的结束而销毁，需要持久化到磁盘则选其他方式

  • hostPath类型的磁盘就是挂在了主机的一个文件或者目录

  • 案例

    • 某些应用需要用到docker的内部文件，这时只需要挂在本机的/var/lib/docker作为hostPath

  

• HostPath有多种类型，列举常见几个

  • Directory 给定的目录路径必须存在
  • DirectoryOrCreate 如果给定路径不存在，将根据需要在那里创建一个空目录
  • File 给定路径上必须存在对应文件
  • FileOrCreate 如果给定路径不存在，将根据需要在那里创建一个空文件

• 案例 volume-hostpath.yaml

xxxxxxxxxx
apiVersion: v1
kind: Pod
metadata:
  name: xdclass-volume-hostpath
  namespace: dev
spec:
  containers:
  - name: xdclass-nginx
    image: nginx:1.20
    ports:
    - containerPort: 80
    volumeMounts:  # 将nginx-log-volume挂在到nginx容器中，对应的目录为 /var/log/nginx
    - name: nginx-log-volume
      mountPath: /var/log/nginx

  - name: xdclass-busybox
    image: busybox:1.35.0 
    command: ["/bin/sh","-c","tail -f /usr/local/test/access.log"] # 容器启动后初始命令，读取指定文件中内容
    volumeMounts:  # 将nginx-log-volume挂在到busybox容器中，对应的目录为 /logs
    - name: nginx-log-volume
      mountPath: /usr/local/test

  volumes: # 这里声明volume存储劵， name为nginx-log-volume，类型是hostPath
  - name: nginx-log-volume
    hostPath:
      path: /usr/local/test
      type: DirectoryOrCreate #如果给定路径不存在，将根据需要在那里创建一个空目录

• 操作

xxxxxxxxxx
#创建
kubectl apply -f volume-hostpath.yaml

#查看
kubectl get pods -n dev -o wide

#访问nignx 产生访问日志
curl ip

#查看容器输出 -f 后是 pod的名称
kubectl logs -f xdclass-volume-hostpath -n dev -c xdclass-busybox

#去节点对应的目录查看文件是否有，即pod运行的节点,主节点上是没的！！！！
ls /usr/local/test

• 删除

xxxxxxxxxx
kubectl delete -f volume-hostpath.yaml

• emptyDir和hostPath对比

  • 都是本地存储卷方式
  • emptyDir是临时存储空间，完全不提供持久化支持；
  • hostPath的卷数据是持久化在node节点的文件系统中的，即便pod已经被删除了，volume卷中的数据还留存在node节点上；

第3集 K8S数据存储ConfigMap实战

简介： K8S数据存储ConfigMap实战

• 需求

  • 很多应用在其初始化或运行期间要依赖一些配置信息
  • 大多数时候， 存在要调整配置参数所设置的数值的需求。
  • ConfigMap 是 Kubernetes 用来向应用 Pod 中注入配置数据的方法

• ConfigMap介绍（缩写cm）

  • 是K8S的一种API对象，用来把【非加密数据】保存到键值对中，比如etcd
  • 可以用作环境变量、命令行参数等，将环境变量、配置信息和容器镜像解耦，便于应用配置的修改

• 使用方式

  • kubectl create configmap 命令，基于目录、 文件或者键值对来创建 ConfigMap

  xxxxxxxxxx
  格式如下
  kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2
  

• 实操

  • 方式一：使用命令行创建

  xxxxxxxxxx
  kubectl create configmap xdclass-config --from-literal=account=xdclass --from-literal=password=123456
  
  #查看
  [root@iZwz90pegu9budx5tk4ruzZ ~]# kubectl get cm xdclass-config -o yaml
  apiVersion: v1
  data:
    account: xdclass
    password: password
  kind: ConfigMap
  metadata:
    creationTimestamp: "2022-07-04T06:36:18Z"
    name: xdclass-config
    namespace: default
    resourceVersion: "1716676"
    selfLink: /api/v1/namespaces/default/configmaps/xdclass-config
    uid: 6ae2890e-fad3-452c-9179-78dd63ddbbba
  

   

  • 方式二：使用文件创建configmap.yaml

  xxxxxxxxxx
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: xdclass-configmap
    namespace: dev
  data:
    info: 
      username:xdclass
      password:123456
  

  • 命令

  xxxxxxxxxx
  #创建
  kubectl create -f configmap.yaml
  
  
  # 查看configmap详情
  kubectl describe cm xdclass-configmap -n dev
  

  • 创建pod的yaml，pod-configmap.yaml，然后吧将创建的configmap挂载进去

  xxxxxxxxxx
  apiVersion: v1
  kind: Pod
  metadata:
    name: pod-configmap
    namespace: dev
  spec:
    containers:
    - name: nginx
      image: nginx:1.20
      volumeMounts: # configmap挂载的目录
      - name: config
        mountPath: /config
  
    volumes: # 声明configmap
    - name: config
      configMap:
        name: xdclass-configmap
  

  • 命令

  xxxxxxxxxx
  #创建pod
  kubectl create -f pod-configmap.yaml
  
  #查看
  kubectl get pod pod-configmap -n dev
  
  #进入容器
  kubectl exec -it pod-configmap -n dev -- /bin/sh
  # cd /config
  # cat info
  
  username:xdclass
  password:123456
  

   

第4集 K8S数据存储之Secret实战

简介： K8S数据存储之Secret实战

• 需求

  • 有些配置需要加密存储，ConfigMap只能使用明文保存，因此不适合

• Secret

  • 用来保存敏感信息，例如密码、秘钥、证书、OAuth 令牌和 ssh key等

  • 就不需要把这些敏感数据暴露到镜像或者Pod中

  • Pod 可以用三种方式之一来使用 Secret：

    • 作为挂载到一个或多个容器上的卷 中的文件
    • 作为容器的环境变量
    • 由 kubelet 在为 Pod 拉取镜像时使用。

  • secret有多个类型

    • dockerconfigjson

      • 用来存储私有 docker registry的认证信息

    • Service Account

      • 只要与Kubernetes API有交互的Pod，都会自动拥有此种类型的Secret
      • K8S自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中

      xxxxxxxxxx
      #查看
      kubectl get pod -A | grep 'kube-proxy'
      
      #进到容器，加了 -- /bin/bash，不会有警告
      kubectl exec -it -n kube-system kube-proxy-9wb4g -- /bin/sh
      
      #查看
      ls -l /run/secrets/kubernetes.io/serviceaccount
      
      cd /run/secrets/kubernetes.io/serviceaccount
      
      cat ca.crt
      

    • Opaque

      • 加密类型为base64，其特点就是将明文改为了密文

      xxxxxxxxxx
      echo -n 'admin' | base64  #账号
      echo -n '123456' | base64 #密码
      
      #创建secret.yaml
      
      apiVersion: v1
      kind: Secret
      metadata:
        name: mysecret
      type: Opaque
      data:
        username: YWRtaW4=
        password: MTIzNDU2
      

      • 命令

      xxxxxxxxxx
      #创建
      kubectl apply -f secret.yaml 
      
      # 查看secret的信息
      kubectl get secret
      
      # 查看mysecret详细信息
      kubectl get secret mysecret -o yaml
      
      #将secret挂载到Pod的Volume中,创建pod-secret-volume.yaml
      apiVersion: v1
      kind: Pod
      metadata:
        name: pod-secret
      spec:
        containers:
        - name: nginx
          image: nginx:1.20
          volumeMounts: # secret挂载
          - name: xdclass-config
            mountPath: /etc/secret
        volumes:
        - name: xdclass-config
          secret:
            secretName: mysecret
      
      #创建pod
      kubectl apply -f pod-secret-volume.yaml
      
      #查看
      kubectl get pod -o wide
      
      #查看secret, 在pod中的secret信息实际已经被解密
      kubectl exec -it pod-secret -- /bin/sh
      #ls /etc/secret
      #cat /etc/secret/username
      #cat /etc/secret/password
      
      
      #删除secret
      kubectl delete secret mysecret