极客时间《Kubernetes 入门实战课》之《Kubernetes 入门实战课》之《初级篇 (9讲)》

极客时间 《Kubernetes 入门实战课》 by 罗剑锋
github上的配套学习项目

《09｜走近云原生：如何在本机搭建小巧完备的Kubernetes环境》

• minikube: 一个“迷你”版本的 Kubernetes

• • 下载和安装minikube, 版本选择了和教程一样的1.25.2:

curl-LOhttps://github.com/kubernetes/minikube/releases/download/v1.25.2/minikube-linux-amd64sudoinstallminikube-linux-amd64 /usr/local/bin/minikube

验证是否安装成功：minikube version查看版本号。

minikube kubectl：下载与当前Kubernetes版本匹配的kubectl （需要科学上网）。

• • 启动minikube ：

minikube start\--image-mirror-country='cn'\--registry-mirror='https://docker.m.daocloud.io,https://docker.mirrors.ustc.edu.cn,https://hub-mirror.c.163.com'\--kubernetes-version=v1.23.3

注意上面的registry-mirror我是参考了 本系列的Docker安装时配置的镜像源。minikube和docker的镜像源配置应该是分开的。比如因为配置了docker的镜像源，所以docker pull nginx:alpine能成功。而如果minikube start时不指定registry-mirror，后面Minikube拉镜像会失败：

registry-mirror的设置成功可以验证：

# 进入 minikubeminikubesshdockerinfo|grep-A10"Registry Mirrors"

看到以下结果：
据说也可以通过进入minikube后，像改docker镜像源那样编辑daemon.json来达到目的，这样启动minikube时都不用指定镜像源了。（未实操）

• • 为简写，给minikube kubectl --命令创建别名：alias kubectl="minikube kubectl --"。注意这样别名只在当前终端生效，想永久保存需要把它写入当前用户的配置文件：

echo'alias kubectl="minikube kubectl --"'>>~/.bashrcsource~/.bashrc

同样的，kubectl的命令自动补全功能：

echo'source <(kubectl completion bash)'>>~/.bashrcsource~/.bashrc

• • 在Kubernetes里运行一个Nginx应用，其中拉取了指定镜像，证明我们的minikube环境搭建成功：
    

《10｜自动化的运维管理：探究Kubernetes工作机制的奥秘》

Kubernetes 里则只有一类人：DevOps。在 Kubernetes 这里，开发和运维的界限变得不那么清晰了。由于云原生的兴起，开发人员从一开始就必须考虑后续的部署运维工作。

• Kubernetes 的基本架构
  
  Kubernetes 采用了现今流行的“控制面 / 数据面”（Control Plane / Data Plane）架构。
  控制面的节点在 Kubernetes 里叫做 Master Node，一般简称为 Master，它是整个集群里最重要的部分，可以说是 Kubernetes 的大脑和心脏。数据面的节点叫做 Worker Node，一般就简称为 Worker 或者 Node。
  Master 和 Node 的划分不是绝对的。当集群的规模较小，Master 也可以承担 Node 的工作，就像我们搭建的 minikube 环境，它就只有一个节点，这个节点既是 Master 又是 Node。

• 节点内部的结构
  Kubernetes 的节点内部的模块可以分成组件（Component）和插件（Addon）两类。
  组件实现了 Kubernetes 的核心功能特性，没有这些组件 Kubernetes 就无法启动。而插件则是 Kubernetes 的一些附加功能，不安装也不会影响 Kubernetes 的正常运行。

• Master 里的组件有哪些
  Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。
  apiserver 是 Master 节点——同时也是整个 Kubernetes 系统的唯一入口，它对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信，可以说是 Kubernetes 里的联络员。
  etcd 是一个高可用的分布式 Key-Value 数据库，用来持久化存储系统里的各种资源对象和状态，相当于 Kubernetes 里的配置管理员。
  scheduler 负责容器的编排工作，检查节点的资源状态，把 Pod 调度到最适合的节点上运行，相当于部署人员。
  controller-manager 负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能，相当于监控运维人员。
  这 4 个组件也都被容器化了，运行在集群的 Pod 里，我们可以用 kubectl 来查看它们的状态：kubectl get pod -n kube-system

• Node 里的组件有哪些
  kubelet、kube-proxy、container-runtime。
  kubelet 是 Node 的代理，负责管理 Node 相关的绝大部分操作，Node 上只有它能够与 apiserver 通信，实现状态报告、命令下发、启停容器等功能。
  kube-proxy是 Node 的网络代理，只负责管理容器的网络通信，简单来说就是为 Pod 转发 TCP/UDP 数据包。
  container-runtime 是容器和镜像的实际使用者，在 kubelet 的指挥下创建容器，管理 Pod 的生命周期。我们这里使用的container-runtime是 Docker。
  这 3 个组件中只有 kube-proxy 被容器化了。

• • Kubernetes 的大致工作流程
    scheduler 通过 apiserver 得到当前的节点状态，调度 Pod，然后 apiserver 下发命令给某个 Node 的 kubelet，kubelet 调用 container-runtime 启动容器。
    controller-manager 也通过 apiserver 得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。

• 插件（Addons）有哪些
  比较重要的有两个：DNS 和 Dashboard。使用命令minikube addons list就可以查看插件列表。列表中看不到DNS，它已经集成到k8s中了。执行minikube dashboard可打开Kubernetes控制台。

《加餐｜Kubernetes“弃用Docker”是怎么回事？》

豆包：Kubernetes “弃用 Docker”，并不是说容器 / 镜像的使用方式变了，而是 Kubernetes改用了 Docker底层的containerd 作为容器运行时，你对镜像和容器的使用体验几乎不会有任何变化。

《11｜YAML：Kubernetes世界里的通用语》

• 什么是 API 对象
  kubectl api-resources查看当前 Kubernetes 版本支持的所有对象

• 如何描述 API 对象
  之前我们运行Nginx的命令 kubectl run ngx --image=nginx:alpine ，和 Docker一样是命令式的。我们来把它改写成“声明式”的 YAML，说清楚我们想要的 Nginx 应用是个什么样子，也就是“目标状态”，让 Kubernetes 自己去决定如何拉取镜像运行：

apiVersion: v1 kind: Pod metadata: name: ngx-pod labels: env: demo owner: chrono spec: containers: - image: nginx:alpine name: ngx ports: - containerPort: 80

这份YAML文档完整地描述了一个类型是 Pod 的 API 对象，要使用 nginx:alpine 镜像创建一个容器，开放端口 80，而其他的部分，就是 Kubernetes 对 API对象强制的格式要求了。

kubectl apply-fngx-pod.yml##创建或更新kubectl delete-fngx-pod.yml##删除

• 如何编写 YAML
  第一个技巧其实前面已经说过了，就是 kubectl api-resources 命令，它会显示出资源对象相应的 API 版本（apiVersion）和类型（kind）;
  第二个技巧，是命令 kubectl explain:
  

第三个技巧就是 kubectl 的两个特殊参数 --dry-run=client 和 -o yaml，前者是空运行，后者是生成 YAML 格式，结合起来使用就会让 kubectl 不会有实际的创建动作，而只生成 YAML 文件。

《12｜Pod：如何理解这个Kubernetes里最核心的概念？》

• 如何使用 YAML 描述 Pod

Pod的container：

• 如何使用 kubectl 操作 Pod

和 Docker 不一样，Kubernetes 的 Pod 不会在前台运行，只能在后台（相当于默认使用了参数 -d），所以输出信息不能直接看到。我们可以用命令kubectl logs，它会把 Pod 的标准输出流信息展示给我们看。

可以使用命令kubectl describe来检查它的详细状态，在调试排错时很有用，通常需要关注的是末尾的“Events”部分：

另外，kubectl 也提供与 docker 类似的cp和exec命令，kubectl cp 可以把本地文件拷贝进 Pod，kubectl exec 是进入 Pod 内部执行 Shell 命令，用法也差不多：

echo'aaa'>a.txt kubectlcpa.txt ngx-pod:/tmp kubectlexec-itngx-pod --sh#格式与Docker有一点小差异，需要在Pod后面加上--

《13｜Job/CronJob：为什么不直接用Pod来处理业务？》

• 为什么要有 Job/CronJob
  “临时任务”就是 API 对象 Job，“定时任务”就是 API 对象 CronJob

• 如何使用 YAML 描述 Job
  也可以用–dry-run=client -o yaml和kubectl create job命令辅助生成Job的YAML文件，比如：
  

• 如何在 Kubernetes 里操作 Job

kubectl apply -f job.yml 运行成功：

activeDeadlineSeconds: 设置Job运行的超时时间。我观察到，如果时间到，Job里没有运行完的Pod会被终止，如：
backoffLimit: 设置 Pod 的失败重试次数。
completions: Job 完成需要运行多少个 Pod，默认是 1 个。
parallelism: 允许并发运行的 Pod 数量。

• 如何使用 YAML 描述 CronJob
  CronJob其实是又组合了 Job 而生成的新对象，三个 spec 嵌套层次：第一个 spec 是 CronJob 自己的对象规格声明。第二个 spec定义了CronJob里的Job对象。第三个 spec定义了 Job 里运行的 Pod：
  
  出于节约资源的考虑，CronJob 不会无限保留已经运行的 Job，它默认只保留 3 个最近的执行结果。

《14｜ConfigMap/Secret：怎样配置、定制我的应用》

《15｜实战演练：玩转Kubernetes（1）》

《16｜视频：初级篇实操总结》