元数据
每天5分钟玩转Kubernetes
- 书名： 每天5分钟玩转Kubernetes
- 作者： CloudMan
- 简介： Kubernetes 是容器编排引擎的事实标准，是继大数据、云计算和 Docker 之后又一热门技术，而且未来相当一段时间内都会非常流行。对于IT行业来说，这是一项非常有价值的技术。对于IT从业者来说，掌握容器技术既是市场的需要，也是提升自我价值的重要途径。 《每天5分钟玩转Kubernetes》共15章，系统介绍了 Kubernetes 的架构、重要概念、安装部署方法、运行管理应用的技术、网络存储管理、集群监控和日志管理等重要内容。书中通过大量实操案例深入浅出地讲解 Kubernetes 核心技术，是一本从入门到进阶的实用Kubernetes 操作指导手册。读者在学习的过程中，可以跟着教程进行操作，在实践中掌握 Kubernetes 的核心技能。在之后的工作中，则可以将本教程作为参考书，按需查找相关知识点。 《每天5分钟玩转 Kubernetes》主要面向微服务软件开发人员，以及 IT 实施和运维工程师等相关人员，也适合作为高等院校和培训学校相关专业的教学参考书。
- 出版时间： 2018-04-01 00:00:00
- ISBN： 9787302496670
- 分类： 计算机-计算机综合
- 出版社： 清华大学出版社
- PC地址：https://weread.qq.com/web/reader/4e7320a07198d71a4e7b700
高亮划线
第1章 先把Kubernetes跑起来
📌 Kubernetes（K8s）是Google在2014年发布的一个开源项目。 ⏱ 2022-06-13 15:12:01
1.3 部署应用
📌 这里Deployment是Kubernetes的术语，可以理解为应用。 ⏱ 2022-06-13 15:14:07
📌 Pod是容器的集合，通常会将紧密相关的一组容器放到一个Pod中，同一个Pod中的所有容器共享IP地址和Port空间，也就是说它们在一个network namespace中。 ⏱ 2022-06-14 09:18:27
📌 Pod是Kubernetes调度的最小单位，同一Pod中的容器始终被一起调度。 ⏱ 2022-06-14 09:18:37
1.4 访问应用
📌 为了能够从外部访问应用，我们需要将容器的8080端口映射到节点的端口。 ⏱ 2022-06-14 09:19:16
1.6 滚动更新
📌 通过kubectl get pods可以观察滚动更新的过程：v1的Pod被逐个删除，同时启动了新的v2 Pod ⏱ 2022-06-14 09:20:17
📌 如果要回退到v1版本也很容易，执行kubectl rollout undo命令 ⏱ 2022-06-14 09:20:29
第2章 重要概念
📌 Cluster是计算、存储和网络资源的集合，Kubernetes利用这些资源运行各种基于容器的应用。 ⏱ 2022-06-14 09:20:55
📌 Master是Cluster的大脑，它的主要职责是调度，即决定将应用放在哪里运行 ⏱ 2022-06-14 09:21:05
📌 Node的职责是运行容器应用。Node由Master管理，Node负责监控并汇报容器的状态，同时根据Master的要求管理容器的生命周期。 ⏱ 2022-06-14 09:21:13
📌 Pod是Kubernetes的最小工作单元。每个Pod包含一个或多个容器。Pod中的容器会作为一个整体被Master调度到一个Node上运行。 ⏱ 2022-06-14 09:21:30
📌 Kubernetes引入Pod主要基于下面两个目的：（1）可管理性。有些容器天生就是需要紧密联系，一起工作。Pod提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes以Pod为最小单位进行调度、扩展、共享资源、管理生命周期。（2）通信和资源共享。Pod中的所有容器使用同一个网络namespace，即相同的IP地址和Port空间。它们可以直接用localhost通信。同样的，这些容器可以共享存储，当Kubernetes挂载volume到Pod，本质上是将volume挂载到Pod中的每一个容器。 ⏱ 2022-06-14 09:21:56
📌 哪些容器应该放到一个Pod中？答案是：这些容器联系必须非常紧密，而且需要直接共享资源。 ⏱ 2022-06-14 09:22:15
📌 Kubernetes通常不会直接创建Pod，而是通过Controller来管理Pod的。Controller中定义了Pod的部署特性，比如有几个副本、在什么样的Node上运行等。 ⏱ 2022-06-14 09:23:19
📌 Kubernetes提供了多种Controller，包括Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job等 ⏱ 2022-06-14 09:23:38
📌 Deployment可以管理Pod的多个副本，并确保Pod按照期望的状态运行。 ⏱ 2022-06-14 09:23:51
📌 ReplicaSet实现了Pod的多副本管理。 ⏱ 2022-06-14 09:23:59
📌 DaemonSet用于每个Node最多只运行一个Pod副本的场景。 ⏱ 2022-06-14 09:24:11
📌 StatefuleSet能够保证Pod的每个副本在整个生命周期中名称是不变的，而其他Controller不提供这个功能 ⏱ 2022-06-14 09:24:34
📌 Job用于运行结束就删除的应用，而其他Controller中的Pod通常是长期持续运行。 ⏱ 2022-06-14 09:24:47
📌 Kubernetes Service定义了外界访问一组特定Pod的方式。Service有自己的IP和端口，Service为Pod提供了负载均衡。 ⏱ 2022-06-14 09:24:55
📌 Namespace可以将一个物理的Cluster逻辑上划分成多个虚拟Cluster，每个Cluster就是一个Namespace。 ⏱ 2022-06-14 09:25:22
3.2 安装kubelet、kubeadm和kubectl
📌 kubelet运行在Cluster所有节点上，负责启动Pod和容器。kubeadm用于初始化Cluster。kubectl是Kubernetes命令行工具。通过kubectl可以部署和管理应用，查看各种资源，创建、删除和更新各种组件。 ⏱ 2022-06-14 09:26:11
3.3 用kubeadm创建Cluster
📌 （1）kubeadm执行初始化前的检查。（2）生成token和证书。（3）生成KubeConfig文件，kubelet需要用这个文件与Master通信。（4）安装Master组件，会从Google的Registry下载组件的Docker镜像。这一步可能会花一些时间，主要取决于网络质量。（5）安装附加组件kube-proxy和kube-dns。（6）Kubernetes Master初始化成功。（7）提示如何配置kubectl，后面会实践。（8）提示如何安装Pod网络，后面会实践。（9）提示如何注册其他节点到Cluster，后面会实践。 ⏱ 2022-06-14 11:40:53
📌 kubectl是管理Kubernetes Cluster的命令行工具 ⏱ 2022-06-14 11:41:29
📌 要让Kubernetes Cluster能够工作，必须安装Pod网络，否则Pod之间无法通信。 ⏱ 2022-06-14 11:47:39
📌 kubectl describe pod
查看Pod的具体情况，比如： ⏱ 2022-06-14 11:48:53 ^26793754-19-5483-5567
第4章 Kubernetes架构
📌 Kubernetes Cluster由Master和Node组成，节点上运行着若干Kubernetes服务。 ⏱ 2022-06-14 11:49:16
4.1 Master节点
📌 Master是Kubernetes Cluster的大脑，运行着的Daemon服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络（例如flannel） ⏱ 2022-06-14 11:49:30
📌 1．API Server（kube-apiserver）API Server提供HTTP/HTTPS RESTful API，即Kubernetes API。 ⏱ 2022-06-14 11:49:51
📌 2．Scheduler（kube-scheduler）Scheduler负责决定将Pod放在哪个Node上运行。Scheduler在调度时会充分考虑Cluster的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。 ⏱ 2022-06-14 11:50:35
📌 3．Controller Manager（kube-controller-manager）Controller Manager负责管理Cluster各种资源，保证资源处于预期的状态。 ⏱ 2022-06-14 11:50:48
📌 etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息 ⏱ 2022-06-14 11:51:10
📌 Pod要能够相互通信，Kubernetes Cluster必须部署Pod网络，flannel是其中一个可选方案 ⏱ 2022-06-14 11:51:31
4.2 Node节点
📌 Node上运行的Kubernetes组件有kubelet、kube-proxy和Pod网络（例如flannel） ⏱ 2022-06-14 11:51:45
📌 kubelet是Node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向Master报告运行状态。 ⏱ 2022-06-14 11:51:53
📌 每个Node都会运行kube-proxy服务，它负责将访问service的TCP/UPD数据流转发到后端的容器。如果有多个副本，kube-proxy会实现负载均衡。 ⏱ 2022-06-14 11:52:07
4.3 完整的架构图
📌 kubelet是唯一没有以容器形式运行的Kubernetes组件，它在Ubuntu中通过Systemd服务运行 ⏱ 2022-06-14 11:52:59
5.1 Deployment
📌 Kubernetes通过各种Controller来管理Pod的生命周期 ⏱ 2022-06-18 12:51:19
📌 Deployment通过ReplicaSet来管理Pod的事实 ⏱ 2022-06-19 11:08:59
📌 （1）用户通过kubectl创建Deployment。（2）Deployment创建ReplicaSet。（3）ReplicaSet创建Pod。 ⏱ 2022-06-19 11:09:36
📌 对象的命名方式是“子对象的名字=父对象名字+随机字符串或数字”。 ⏱ 2022-06-19 11:09:44
📌 基于配置文件的方式：配置文件描述了What，即应用最终要达到的状态。配置文件提供了创建资源的模板，能够重复部署。可以像管理代码一样管理部署。适合正式的、跨环境的、规模化部署。这种方式要求熟悉配置文件的语法，有一定难度。 ⏱ 2022-06-19 11:10:14
📌 ①apiVersion是当前配置格式的版本。②kind是要创建的资源类型，这里是Deployment。③metadata是该资源的元数据，name是必需的元数据项。④spec部分是该Deployment的规格说明。⑤replicas指明副本数量，默认为1。⑥template定义Pod的模板，这是配置文件的重要部分。⑦metadata定义Pod的元数据，至少要定义一个label。label的key和value可以任意指定。⑧spec描述Pod的规格，此部分定义Pod中每一个容器的属性，name和image是必需的。 ⏱ 2022-06-19 11:12:55
📌 如果要删除这些资源，执行kubectl delete deployment nginx-deployment或者kubectl delete -f nginx.yml ⏱ 2022-06-19 11:15:24
📌 伸缩是指在线增加或减少Pod的副本数。 ⏱ 2022-06-19 11:15:27
📌 等待一段时间，Kubernetes会检查到k8s-node2不可用，将k8s-node2上的Pod标记为Unknown状态，并在k8s-node1上新创建两个Pod，维持总副本数为3， ⏱ 2022-06-19 11:16:08
📌 默认配置下，Scheduler会将Pod调度到所有可用的Node。不过有些情况我们希望将Pod部署到指定的Node，比如将有大量磁盘I/O的Pod部署到配置了SSD的Node；或者Pod需要GPU，需要运行在配置了GPU的节点上。 ⏱ 2022-06-19 11:16:22
📌 label是key-value对，各种资源都可以设置label，灵活添加各种自定义属性 ⏱ 2022-06-19 11:16:25
📌 在Pod模板的spec里通过nodeSelector指定将此Pod部署到具有label disktype=ssd的Node上。 ⏱ 2022-06-19 11:19:03
5.2 DaemonSet
📌 DaemonSet的不同之处在于：每个Node上最多只能运行一个副本。 ⏱ 2022-06-19 11:19:26
📌 hostName指定Pod直接使用的是Node网络，相当于docker run —network=host。考虑到flannel需要为集群提供网络连接，这个要求是合理的。 ⏱ 2022-06-20 10:28:38
📌 Kubernetes集群中每个当前运行的资源都可以通过kubectl edit查看其配置和运行状态 ⏱ 2022-06-20 10:29:08
5.3 Job
📌 容器按照持续运行的时间可分为两类：服务类容器和工作类容器。 ⏱ 2022-06-20 10:30:11
📌 服务类容器通常持续提供服务，需要一直运行，比如HTTP Server、Daemon等。工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。 ⏱ 2022-06-20 10:30:18
📌 restartPolicy指定什么情况下需要重启容器。对于Job，只能设置为Never或者OnFailure。对于其他controller（比如Deployment），可以设置为Always。 ⏱ 2022-06-20 10:30:32
📌 通过kubectl describe pod查看某个Pod的启动日志 ⏱ 2022-06-20 10:31:01
📌 Job DESIRED的Pod是1，目前SUCCESSFUL为0，不满足 ⏱ 2022-06-20 10:31:25
📌 有时我们希望能同时运行多个Pod，提高Job的执行效率。这个可以通过parallelism设置 ⏱ 2022-06-20 10:31:42
📌 Kubernetes的CronJob提供了类似的功能，可以定时执行Job ⏱ 2022-06-20 10:32:00
📌 schedule指定什么时候运行Job，其格式与Linux cron一致。这里*/1 * * * *的含义是每一分钟启动一次。 ⏱ 2022-06-20 10:32:06
5.4 小结
📌 运行容器化应用是Kubernetes最重要的核心功能。为满足不同的业务需要，Kubernetes提供了多种Controller，包括Deployment、DaemonSet、Job、CronJob等。 ⏱ 2022-06-20 10:33:46
第6章 通过Service访问Pod
📌 Pod是脆弱的，但应用是健壮的。 ⏱ 2022-06-20 10:34:02
📌 如果一组Pod对外提供服务（比如HTTP），它们的IP很有可能发生变化，那么客户端如何找到并访问这个服务呢？Kubernetes给出的解决方案是Service。 ⏱ 2022-06-20 10:34:13
6.1 创建Service
📌 Kubernetes Service从逻辑上代表了一组Pod，具体是哪些Pod则是由label来挑选的 ⏱ 2022-06-20 10:34:19
📌 Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。 ⏱ 2022-06-20 10:34:35
📌 Pod分配了各自的IP，这些IP只能被Kubernetes Cluster中的容器和节点访问 ⏱ 2022-06-20 10:35:18
📌 Service kubernetes，Cluster内部通过这个Service访问Kubernetes API Server。 ⏱ 2022-06-20 10:35:52
📌 Service的Cluster IP又是配置在哪里的呢？CLUSTER-IP又是如何映射到Pod IP的呢？答案是iptables。 ⏱ 2022-06-20 10:36:14
6.2 Cluster IP底层实现
📌 Cluster IP是一个虚拟IP，是由Kubernetes节点上的iptables规则管理的。 ⏱ 2022-06-20 10:36:23
📌 iptables将访问Service的流量转发到后端Pod，而且使用类似轮询的负载均衡策略。 ⏱ 2022-06-20 10:37:10
📌 Cluster的每一个节点都配置了相同的iptables规则，这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service ⏱ 2022-06-20 10:37:16
6.3 DNS访问Service
📌 在Cluster中，除了可以通过Cluster IP访问Service，Kubernetes还提供了更为方便的DNS访问。 ⏱ 2022-06-20 10:37:29
📌 kube-dns是一个DNS服务器。每当有新的Service被创建，kube-dns会添加该Service的DNS记录。Cluster中的Pod可以通过<SERVICE_NAME>.<NAMESPACE_NAME>访问Service。 ⏱ 2022-06-20 10:37:42
📌 另外，由于这个Pod与httpd-svc同属于default namespace，因此可以省略default直接用httpd-svc访问Service ⏱ 2022-06-20 10:38:36
📌 DNS服务器是kube-dns.kube-system.svc.cluster.local，这实际上就是kube-dns组件，它本身是部署在kube-system namespace中的一个Service。 ⏱ 2022-06-20 10:38:25
📌 如果要访问其他namespace中的Service，就必须带上namesapce了 ⏱ 2022-06-20 10:38:55
📌 多个资源可以在一个YAML文件中定义，用“---”分割 ⏱ 2022-06-20 10:39:04
6.4 外网如何访问Service
📌 Service通过Cluster内部的IP对外提供服务，只有Cluster内的节点和Pod可访问，这是默认的Service类型 ⏱ 2022-06-20 10:39:40
📌 Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过
: 访问Service。 ⏱ 2022-06-20 10:39:52 ^26793754-36-870-942
📌 Service利用cloud provider特有的load balancer对外提供服务，cloud provider负责将load balancer的流量导向Service。 ⏱ 2022-06-20 10:39:57
📌 与ClusterIP一样，也是借助了iptables ⏱ 2022-06-20 10:40:18
📌 nodePort是节点上监听的端口。port是ClusterIP上监听的端口。targetPort是Pod监听的端口。 ⏱ 2022-06-20 10:40:37
第7章 Rolling Update
📌 滚动更新是一次只更新一小部分副本，成功后再更新更多的副本，最终完成所有副本的更新。 ⏱ 2022-06-20 10:41:17
📌 滚动更新的最大好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。 ⏱ 2022-06-20 10:41:22
7.1 实践
📌 每次替换的Pod数量是可以定制的。Kubernetes提供了两个参数maxSurge和maxUnavailable来精细控制Pod的替换数量 ⏱ 2022-06-20 10:42:53
7.2 回滚
📌 kubectl apply每次更新应用时，Kubernetes都会记录下当前的配置，保存为一个revision（版次），这样就可以回滚到某个特定revision。 ⏱ 2022-06-20 10:43:01
📌 —record的作用是将当前命令记录到revision记录中，这样我们就可以知道每个revison对应的是哪个配置文件了 ⏱ 2022-06-20 10:43:21
📌 一定要在执行kubectl apply时加上—record参数 ⏱ 2022-06-20 10:44:55
第8章 Health Check
📌 强大的自愈能力是Kubernetes这类容器编排引擎的一个重要特性。 ⏱ 2022-06-20 10:45:06
📌 自愈的默认实现方式是自动重启发生故障的容器 ⏱ 2022-06-20 10:45:07
8.1 默认的健康检查
📌 每个容器启动时都会执行一个进程，此进程由Dockerfile的CMD或ENTRYPOINT指定。如果进程退出时返回码非零，则认为容器发生故障，Kubernetes就会根据restartPolicy重启容器。 ⏱ 2022-06-20 10:45:27
📌 比如访问Web服务器时显示500内部错误，可能是系统超载，也可能是资源死锁，此时httpd进程并没有异常退出，在这种情况下重启容器可能是最直接、最有效的解决方案 ⏱ 2022-06-20 12:14:11
📌 Liveness探测。 ⏱ 2022-06-20 12:14:17
8.2 Liveness探测
📌 Liveness探测让用户可以自定义判断容器是否健康的条件 ⏱ 2022-06-20 12:14:21
📌 livenessProbe部分定义如何执行Liveness探测：（1）探测的方法是：通过cat命令检查/tmp/healthy文件是否存在。如果命令执行成功，返回值为零，Kubernetes则认为本次Liveness探测成功；如果命令返回值非零，本次Liveness探测失败。 ⏱ 2022-06-20 12:15:01
📌 ）initialDelaySeconds：10指定容器启动10之后开始执行Liveness探测，我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花30秒，那么initialDelaySeconds的值就应该大于30。 ⏱ 2022-06-20 12:15:09
📌 periodSeconds：5指定每5秒执行一次Liveness探测。Kubernetes如果连续执行3次Liveness探测均失败，则会杀掉并重启容器。 ⏱ 2022-06-20 12:15:20
8.3 Readiness探测
📌 Readiness探测则是告诉Kubernetes什么时候可以将容器加入到Service负载均衡池中，对外提供服务 ⏱ 2022-06-20 12:15:39
📌 30秒后，/tmp/healthy被删除，连续3次Readiness探测均失败后，READY被设置为不可用。 ⏱ 2022-06-20 12:16:17
📌 （1）Liveness探测和Readiness探测是两种Health Check机制，如果不特意配置，Kubernetes将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。 ⏱ 2022-06-20 12:16:27
📌 Liveness探测是重启容器；Readiness探测则是将容器设置为不可用，不接收Service转发的请求。 ⏱ 2022-06-20 12:16:30
📌 （3）Liveness探测和Readiness探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用Liveness探测判断容器是否需要重启以实现自愈；用Readiness探测判断容器是否已经准备好对外提供服务。 ⏱ 2022-06-20 12:16:38
8.4 Health Check在Scale Up中的应用
📌 我们可以通过Readiness探测判断容器是否就绪，避免将请求发送到还没有准备好的backend。 ⏱ 2022-06-20 12:17:22
📌 这里我们使用了不同于exec的另一种探测方法httpGet。Kubernetes对于该方法探测成功的判断条件是http请求的返回代码在200～400之间。 ⏱ 2022-06-20 12:17:40
📌 对于生产环境中重要的应用，都建议配置Health Check，保证处理客户请求的容器都是准备就绪的Service backend。 ⏱ 2022-06-20 12:25:49
8.5 Health Check在滚动更新中的应用
📌 Health Check另一个重要的应用场景是Rolling Update ⏱ 2022-06-20 12:25:53
📌 如果正确配置了Health Check，新副本只有通过了Readiness探测才会被添加到Service；如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。 ⏱ 2022-06-20 13:06:41
📌 滚动更新通过参数maxSurge和maxUnavailable来控制副本替换的数量。 ⏱ 2022-06-20 13:07:13
📌 1．maxSurge此参数控制滚动更新过程中副本总数超过DESIRED的上限。 ⏱ 2022-06-20 13:07:20
📌 2．maxUnavailable此参数控制滚动更新过程中，不可用的副本相占DESIRED的最大比例。maxUnavailable可以是具体的整 ⏱ 2022-06-20 13:07:34
📌 maxSurge值越大，初始创建的新副本数量就越多；maxUnavailable值越大，初始销毁的旧副本数量就越多。 ⏱ 2022-06-20 13:07:40
📌 如果滚动更新失败，可以通过kubectl rollout undo回滚到上一个版本 ⏱ 2022-06-20 13:07:49
9.1 Volume
📌 为了持久化保存容器的数据，可以使用Kubernetes Volume。 ⏱ 2022-06-20 13:08:47
📌 Volume的生命周期独立于容器，Pod中的容器可能被销毁和重建，但Volume会被保留。 ⏱ 2022-06-20 13:08:32
📌 当Volume被mount到Pod，Pod中的所有容器都可以访问这个Volume。Kubernetes Volume也支持多种backend类型，包括emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph等 ⏱ 2022-06-20 13:08:55
📌 emptyDir是最基础的Volume类型。正如其名字所示，一个emptyDir Volume是Host上的一个空目录。 ⏱ 2022-06-20 13:09:11
📌 emptyDir Volume对于容器来说是持久的，对于Pod则不是。当Pod从节点删除时，Volume的内容也会被删除。但如果只是容器被销毁而Pod还在，则Volume不受影响。 ⏱ 2022-06-20 13:09:23
📌 emptyDir Volume的生命周期与Pod一致。 ⏱ 2022-06-20 13:09:24
📌 因为emptyDir是Docker Host文件系统里的目录，其效果相当于执行了docker run -v/producer_dir和docker run -v /consumer_dir。 ⏱ 2022-06-20 13:13:11
📌 emptyDir是Host上创建的临时目录，其优点是能够方便地为Pod中的容器提供共享存储，不需要额外的配置。它不具备持久性，如果Pod不存在了，emptyDir也就没有了。 ⏱ 2022-06-20 13:13:24
📌 emptyDir特别适合Pod中的容器需要临时共享存储空间的场景，比如前面的生产者消费者用例 ⏱ 2022-06-20 13:13:27
📌 hostPath Volume的作用是将Docker Host文件系统中已经存在的目录mount给Pod的容器 ⏱ 2022-06-20 13:13:36
📌 Kubernetes Volume也可以使用主流的分布式存储，比如Ceph、GlusterFS等 ⏱ 2022-06-20 13:14:05
📌 Volume的底层基础设施由独立的存储系统管理，与Kubernetes集群是分离的 ⏱ 2022-06-20 13:14:12
9.2 PersistentVolume & PersistentVolumeClaim
📌 PersistentVolume（PV）是外部存储系统中的一块存储空间，由管理员创建和维护。与Volume一样，PV具有持久性，生命周期独立于Pod。PersistentVolumeClaim （PVC）是对PV的申请（Claim）。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes会查找并提供满足条件的PV。 ⏱ 2022-06-20 13:14:45
📌 Kubernetes支持多种类型的PersistentVolume，比如AWS EBS、Ceph、NFS等 ⏱ 2022-06-20 13:14:59
📌 accessModes指定访问模式为ReadWriteOnce，支持的访问模式有3种：ReadWriteOnce表示PV能以read-write模式mount到单个节点，ReadOnlyMany表示PV能以read-only模式mount到多个节点，ReadWriteMany表示PV能以read-write模式mount到多个节点。 ⏱ 2022-06-20 13:15:54
📌 persistentVolumeReclaimPolicy指定当PV的回收策略为Recycle，支持的策略有3种：Retain表示需要管理员手工回收；Recycle表示清除PV中的数据，效果相当于执行rm -rf/thevolume/*；Delete表示删除Storage Provider上的对应存储资源，例如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume等。 ⏱ 2022-06-20 13:15:47
📌 当不需要使用PV时，可用删除PVC回收PV ⏱ 2022-06-20 13:16:28
📌 当PVC mypvc1被删除后，我们发现Kubernetes启动了一个新Pod recycler-for-mypv1，这个Pod的作用就是清除PV mypv1的数据。 ⏱ 2022-06-20 13:23:07
📌 提前创建了PV，然后通过PVC申请PV并在Pod中使用，这种方式叫作静态供给（Static Provision） ⏱ 2022-06-20 13:24:03
📌 与之对应的是动态供给（Dynamical Provision），即如果没有满足PVC条件的PV，会动态创建PV。相比静态供给，动态供给有明显的优势：不需要提前创建PV，减少了管理员的工作量，效率高。 ⏱ 2022-06-20 13:24:14
📌 动态供给是通过StorageClass实现的， ⏱ 2022-06-20 13:24:20
9.4 小结
📌 PV和PVC分离了管理员和普通用户的职责，更适合生产环境。我们还学习了如何通过StorageClass实现更高效的动态供给。 ⏱ 2022-06-20 13:26:23
第10章 Secret & Configmap
📌 Secret会以Volume的形式被mount到Pod，容器可通过文件的方式使用Secret中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。 ⏱ 2022-06-20 13:26:36
10.1 创建Secret
📌 文件中的敏感数据必须是通过base64编码后的结果 ⏱ 2022-06-20 13:27:07
10.2 查看Secret
📌 通过kubectl describe secret查看条目的Key ⏱ 2022-06-20 13:27:54
10.3 在Pod中使用Secret
📌 Pod可以通过Volume或者环境变量的方式使用Secret。 ⏱ 2022-06-20 13:27:59
📌 Kubernetes会在指定的路径/etc/foo下为每条敏感数据创建一个文件，文件名就是数据条目的Key，这里是/etc/foo/username和/etc/foo/password，Value则以明文存放在文件中。 ⏱ 2022-06-20 13:28:27
📌 以Volume方式使用的Secret支持动态更新：Secret更新后，容器中的数据也会更新。 ⏱ 2022-06-20 13:28:36
📌 Kubernetes还支持通过环境变量使用Secret。 ⏱ 2022-06-20 13:28:45
📌 需要注意的是，环境变量读取Secret很方便，但无法支撑Secret动态更新。 ⏱ 2022-06-20 13:28:50
10.4 ConfigMap
📌 Secret可以为Pod提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用ConfigMap。 ⏱ 2022-06-20 13:28:57
📌 ConfigMap的创建和使用方式与Secret非常类似，主要的不同是数据以明文的形式存放。 ⏱ 2022-06-20 13:29:02
📌 与Secret一样，Pod也可以通过Volume或者环境变量的方式使用Secret。 ⏱ 2022-06-20 13:29:15
📌 注意，别漏写了Key logging.conf后面的|符号。 ⏱ 2022-06-20 13:30:00
10.5 小结
📌 Secret和ConfigMap支持四种定义方法。Pod在使用它们时，可以选择Volume方式或环境变量方式，不过只有Volume方式支持动态更新。 ⏱ 2022-06-20 13:30:23
第11章 Helm— Kubernetes的包管理器
📌 Helm则是Kubernetes上的包管理器。 ⏱ 2022-06-20 13:30:28
11.1 Why Helm
📌 Kubernetes能够很好地组织和编排容器，但它缺少一个更高层次的应用打包工具，而Helm就是来干这件事的 ⏱ 2022-06-20 13:30:35
📌 Helm帮助Kubernetes成为微服务架构应用理想的部署平台。 ⏱ 2022-06-20 13:33:14
11.2 Helm架构
📌 chart是创建一个应用的信息集合，包括各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等。chart是应用部署的自包含逻辑单元。可以将chart想象成apt、yum中的软件安装包。 ⏱ 2022-06-20 13:33:21
📌 release是chart的运行实例，代表了一个正在运行的应用。当chart被安装到Kubernetes集群，就生成一个release。chart能够多次安装到同一个集群，每次安装都是一个release。 ⏱ 2022-06-20 13:33:33
📌 Helm是包管理工具，这里的包就是指的chart。Helm能够：从零创建新chart。与存储chart的仓库交互，拉取、保存和更新chart。在Kubernetes集群中安装和卸载release。更新、回滚和测试release。 ⏱ 2022-06-20 13:33:47
📌 Helm客户端是终端用户使用的命令行工具，用户可以：在本地开发chart。管理chart仓库。与Tiller服务器交互。在远程Kubernetes集群上安装chart。查看release信息。升级或卸载已有的release。 ⏱ 2022-06-20 13:33:57
📌 Helm客户端负责管理chart，Tiller服务器负责管理release。 ⏱ 2022-06-20 13:34:03
11.3 安装Helm
📌 Tiller本身也是作为容器化应用运行在Kubernetes Cluster中的 ⏱ 2022-06-20 13:34:35
11.4 使用Helm
📌 Helm安装时已经默认配置好了两个仓库：stable和local。stable是官方仓库，local是用户存放自己开发的chart的本地仓库。 ⏱ 2022-06-20 13:34:44
11.5 chart详解
📌 chart是Helm的应用打包格式。chart由一系列文件组成，这些文件描述了Kubernetes部署应用时所需要的资源，比如Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap等。 ⏱ 2022-06-20 13:39:57
📌 chart将这些文件放置在预定义的目录结构中，通常整个chart被打成tar包，而且标注上版本信息，便于Helm部署。 ⏱ 2022-06-20 13:40:08
📌 一旦安装了某个chart，我们就可以在~/.helm/cache/archive中找到chart的tar包 ⏱ 2022-06-20 13:40:27
📌 chart可能依赖其他的chart，这些依赖关系可通过requirements.yaml指定 ⏱ 2022-06-20 13:42:19
📌 chart支持在安装时根据参数进行定制化配置，而values.yaml则提供了这些配置参数的默认值 ⏱ 2022-06-20 13:42:28
📌 模板是chart最重要的部分，也是Helm最强大的地方。模板增加了应用部署的灵活性，能够适用不同的环境，我们后面会详细讨论。 ⏱ 2022-06-20 13:42:36
📌 （7）templates/NOTES.txtchart的简易使用文档，chart安装成功后会显示此文档内容 ⏱ 2022-06-20 13:42:45
📌 Helm采用了Go语言的模板来编写chart ⏱ 2022-06-20 13:42:56
📌 如果存在一些信息多个模板都会用到，则可在templates/_helpers.tpl中将其定义为子模板，然后通过templates函数引用。 ⏱ 2022-06-20 13:43:11
📌 作为准备工作，安装之前需要先清楚chart的使用方法。这些信息通常记录在values.yaml和README.md中。除了下载源文件查看，执行helm inspect values可能是更方便的方法 ⏱ 2022-06-20 13:44:12
📌 输出的实际上是values.yaml的内容。 ⏱ 2022-06-20 13:44:23
📌 Helm有两种方式传递配置参数：（1）指定自己的values文件。通常的做法是首先通过helm inspect values mysql > myvalues.yaml生成values文件，然后设置 ⏱ 2022-06-20 13:44:52
📌 （2）通过—set直接传入参数值 ⏱ 2022-06-20 13:44:55
📌 release发布后可以执行helm upgrade对其进行升级，通过—values或—set应用新的配置。 ⏱ 2022-06-20 13:45:05
📌 执行helm create mychart命令，创建chart mychart， ⏱ 2022-06-20 13:45:18
📌 Helm提供了debug的工具：helm lint和helm install —dry-run —debug。helm lint会检测chart的语法，报告错误以及给出建议。 ⏱ 2022-06-20 17:25:36
📌 。Helm支持四种安装方法：（1）安装仓库中的chart，例如helm install stable/nginx。（2）通过tar包安装，例如helm install./nginx-1.2.3.tgz。（3）通过chart本地目录安装，例如helm install./nginx。（4）通过URL安装，例如helm install https://example.com/charts/nginx-1.2.3.tgz。 ⏱ 2022-06-20 17:26:01
📌 Helm会扫描myrepo目录中的所有tgz包并生成index.yaml。—url指定的是新仓库的访问路径。 ⏱ 2022-06-20 17:26:43
11.6 小结
📌 Helm让我们能够像apt管理deb包那样安装、部署、升级和删除容器化应用。 ⏱ 2022-06-20 17:26:59
📌 Helm由客户端和Tiller服务器组成。客户端负责管理chart，服务器负责管理release。 ⏱ 2022-06-20 17:26:57
📌 chart是Helm的应用打包格式，它由一组文件和目录构成。其中最重要的是模板，模板中定义了Kubernetes各类资源的配置信息，Helm在部署时通过values.yaml实例化模板。 ⏱ 2022-06-20 17:27:02
12.1 Kubernetes网络模型
📌 集群中的每个Pod都有自己的IP地址，Pod之间不需要配置NAT就能直接通信。另外，同一个Pod中的容器共享Pod的IP，能够通过localhost通信。 ⏱ 2022-06-20 17:49:21
📌 当Pod被调度到某个节点，Pod中的所有容器都在这个节点上运行，这些容器共享相同的本地文件系统、IPC和网络命名空间。 ⏱ 2022-06-20 17:49:36
📌 不同Pod之间不存在端口冲突的问题，因为每个Pod都有自己的IP地址 ⏱ 2022-06-20 17:49:40
📌 Pod的IP是集群可见的，即集群中的任何其他Pod和节点都可以通过IP直接与Pod通信，这种通信不需要借助任何网络地址转换、隧道或代理技术 ⏱ 2022-06-20 17:50:27
📌 3．Pod与Service的通信Pod间可以直接通过IP地址通信，但前提是Pod知道对方的IP。在Kubernetes集群中，Pod可能会频繁地销毁和创建，也就是说Pod的IP不是固定的。为了解决这个问题，Service提供了访问Pod的抽象层。无论后端的Pod如何变化，Service都作为稳定的前端对外提供服务。同时，Service还提供了高可用和负载均衡功能，Service负责将请求转发给正确的Pod。 ⏱ 2022-06-20 17:50:36
📌 NodePort。Service通过Cluster节点的静态端口对外提供服务。外部可以通过
: 访问Service。LoadBalancer。Service利用cloud provider提供的load balancer对外提供服务，cloud provider负责将load balancer的流量导向Service。目前支持的cloud provider有GCP、AWS、Azur等。 ⏱ 2022-06-20 17:50:52 ^26793754-68-2048-2287
📌 Kubernetes采用了Container Networking Interface（CNI）规范 ⏱ 2022-06-20 17:51:00
📌 CNI是由CoreOS提出的容器网络规范，使用了插件（Plugin）模型创建容器的网络栈 ⏱ 2022-06-20 17:51:04
📌 CNI的优点是支持多种容器runtime，不仅仅是Docker ⏱ 2022-06-20 17:51:09
12.3 Network Policy
📌 Network Policy通过Label选择Pod，并指定其他Pod或外界如何与这些Pod通信。 ⏱ 2022-06-20 17:51:24
📌 当为Pod定义了Network Policy时，只有Policy允许的流量才能访问Pod。 ⏱ 2022-06-20 17:51:47
📌 不是所有的Kubernetes网络方案都支持Network Policy。比如Flannel就不支持，Calico是支持的 ⏱ 2022-06-20 17:51:35
📌 Canal这个开源项目很有意思，它用Flannel实现Kubernetes集群网络，同时又用Calico实现Network Policy。 ⏱ 2022-06-20 17:52:01
📌 没有太好的办法直接切换使用不同的网络方案，基本上只能重新创建集群。 ⏱ 2022-06-20 17:52:10
📌 要销毁当前集群，最简单的方法是在每个节点上执行kubeadm reset ⏱ 2022-06-20 17:52:22
📌 除了通过ingress限制进入的流量，也可以用egress限制外出的流量 ⏱ 2022-06-20 18:05:13
12.4 小结
📌 Network Policy赋予了Kubernetes强大的网络访问控制机制。 ⏱ 2022-06-20 18:05:18
14.1 Weave Scope
📌 Weave Scope是Docker和Kubernetes可视化监控工具。 ⏱ 2022-06-20 18:12:07
14.2 Heapster
📌 Heapster是Kubernetes原生的集群监控方案。 ⏱ 2022-06-20 18:12:31
📌 Heapster以Pod的形式运行，它会自动发现集群节点，从节点上的Kubelet获取监控数据。Kubelet则是从节点上的cAdvisor收集数据。 ⏱ 2022-06-20 18:22:05
14.3 Prometheus Operator
📌 我们通常还希望监控集群本身的运行状态，比如Kubernetes的API Server、Scheduler、Controller Manager等管理组件是否正常工作以及负荷是否过大等 ⏱ 2022-06-20 18:22:30
📌 Prometheus提供了数据搜集、存储、处理、可视化和告警一套完整的解决方案 ⏱ 2022-06-20 18:22:52
📌 Prometheus Server负责从Exporter拉取和存储监控数据，并提供一套灵活的查询语言（PromQL）供用户使用。 ⏱ 2022-06-20 18:23:09
📌 Exporter负责收集目标对象（host、container等）的性能数据，并通过HTTP接口供Prometheus Server获取。 ⏱ 2022-06-20 18:23:10
📌 Grafana能够与Prometheus无缝集成，提供完美的数据展示能力。 ⏱ 2022-06-20 18:23:16
14.4 小结
📌 Prometheus Operator可能是目前功能最全面的Kubernetes开源监控方案。除了能够监控Node和Pod，还支持集群的各种管理组件，比如API Server、Scheduler、Controller Manager等。 ⏱ 2022-06-20 18:24:20
第15章 Kubernetes集群日志管理
📌 Elasticsearch是一个搜索引擎，负责存储日志并提供查询接口；Fluentd负责从Kubernetes搜集日志并发送给Elasticsearch；Kibana提供了一个Web GUI，用户可以浏览和搜索存储在Elasticsearch中的日志 ⏱ 2022-06-20 18:24:30
15.1 部署
📌 Elasticsearch以StatefulSet资源运行，并通过Service elasticsearch-logging对外提供接口 ⏱ 2022-06-20 18:24:55