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

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

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

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

curl -LO https://github.com/kubernetes/minikube/releases/download/v1.25.2/minikube-linux-amd64
sudo install minikube-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的设置成功可以验证：

# 进入 minikube
minikube ssh
docker info | grep -A 10 "Registry Mirrors"

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

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

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

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

echo 'source <(kubectl completion bash)' >> ~/.bashrc
source ~/.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 -f ngx-pod.yml   ##创建或更新
kubectl delete -f ngx-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
kubectl cp a.txt ngx-pod:/tmp

kubectl exec -it ngx-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：怎样配置、定制我的应用》

• ConfigMap/Secret
  ConfigMap 用来保存明文配置，Secret 用来保存秘密配置

• 什么是 ConfigMap
  ConfigMap的Key-Value信息存入etcd数据库

• 如何以环境变量的方式使用 ConfigMap/Secret

  我：注意env是容器的环境变量：
  
  可以比较下文《15｜实战演练：玩转Kubernetes（1）》中的envFrom字段。

• 如何以 Volume 的方式使用 ConfigMap/Secret

  注意 volumes字段属于 Pod，不属于容器，它和字段containers是同级的：
  
  进入Pod后可以看到，ConfigMap 和 Secret 都变成了目录的形式，而它们里面的 Key-Value 变成了一个个的文件，而文件名就是 Key：
  

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

• Kubernetes 技术要点回顾
  Kubernetes 里有很多的 API 对象，其中最核心的对象是“Pod”，它捆绑了一组存在密切协作关系的容器，容器之间共享网络和存储，在集群里必须一起调度一起运行。

• WordPress 网站搭建步骤

注意这里我们使用了一个新的字段envFrom，这是因为 ConfigMap 里的信息比较多，如果用 env.valueFrom 一个个地写会非常麻烦，容易出错，而 envFrom 可以一次性地把 ConfigMap 里的字段全导入进 Pod。

进入Pod内部验证创建的变量：

• • 为 WordPress Pod 映射端口号，让它在集群外可见:
    因为 Pod 都是运行在 Kubernetes 内部的私有网段里的，外界无法直接访问，想要对外暴露服务，需要使用一个专门的 kubectl port-forward 命令，它专门负责把本机的端口映射到在目标对象的端口号，有点类似 Docker 的参数 -p。
    e.g., 将名为"wp-pod"的Pod的80端口映射到本地主机的8080端口, 命令中的"&"符号表示在后台运行命令：kubectl port-forward wp-pod 8080:80 &

注意：后面评论里作者提到： port-forward只能用于测试，生产环境当然要用Ingress

• • minikube dashboard
    点击任意一个 Pod 的名字，就会进入管理界面，可以看到 Pod 的详细信息，而右上角有 4 个很重要的功能，分别可以查看日志、进入 Pod 内部、编辑 Pod 和删除 Pod，相当于执行 logs、exec、edit、delete 命令，但要比命令行要直观友好的多：
    

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

我：minikube以driver=docker方式（默认）启动时，会启动kicbase容器。此时我们运行minikube ssh，会登录进kicbase容器内部。kicbase容器内部预装了一套独立的容器运行时，自带网桥docker0，k8s运行的所有pod及其内部容器，都在这个网桥上。
其本质是容器套容器（DinD：Docker-in-Docker）架构。

我：我在宿主机手动新建容器，则会使用默认网桥 docker0（不是上段的docker0）， 网段是 172.17.0.0/16，新容器应该访问不到minikube容器了吧？（因为minikube自动创建专属网桥，子网是192.168.49.0）
豆包：对，但有办法互通。可以让新容器加入 minikube 同网络，启动后它的IP 会是 192.168.49.x：