qq_32468785的博客

云计算是一种通过计算机网络以服务的方式提供动态可伸缩的虚拟化资源的计算模式。按照服务层次分为IaaS、PaaS和SaaS三个层次；按照部署方式可以分成公有云、私有云和混合云。云计算优点弹性伸缩：云计算可以根据业务需求自动调整计算资源，使应用程序可以在高峰期和低谷期之间自由地进行伸缩。资源共享：云计算可以将计算资源、存储资源和网络资源等进行共享，从而实现资源的高效利用。成本效益：云计算可以提供按需计费的服务模式，避免了购买昂贵的硬件设备和维护成本。

Role 和 RoleBinding 对象都是 Namespaced 对象（Namespaced Object），它们对权限的限制规则仅在它们自己的 Namespace 内有效，roleRef 也只能引用当前 Namespace 里的 Role 对象。那么，对于非 Namespaced（Non-namespaced）对象（比如：Node），或者，某一个 Role 想要作用于所有的 Namespace 的时候，我们又该如何去做授权呢？

PVC 描述的，是 Pod 想要使用的持久化存储的属性，比如存储的大小、读写权限等。PV 描述的，则是一个具体的 Volume 的属性，比如 Volume 的类型、挂载目录、远程存储服务器地址等。而 StorageClass 的作用，则是充当 PV 的模板。并且，只有同属于一个 StorageClass 的 PV 和 PVC，才可以绑定在一起。当然，StorageClass 的另一个重要作用，是指定 PV 的 Provisioner（存储插件）。

在 Kubernetes 中，默认情况下，Pod 具有“接受全部”（Accept All）的网络访问权限，也就是说，Pod 可以接收来自任何发送方的请求，并向任何接收方发送请求。如果需要对此进行限制，必须通过 NetworkPolicy 对象来设置规则。在上面这个例子中，可以看到 podSelector 字段，它的作用是定义 NetworkPolicy 的作用范围，例如当前命名空间中带有 role=db 标签的 Pod。

Flannel 是一个用于容器网络的开源解决方案，它使用了虚拟网络接口技术（如 VXLAN）和 etcd 存储来提供网络服务。Flannel 协助 Kubernetes，给每一个 Node 上的 Dockers 容器都分配互不冲突的 IP 地址。它能在这些 IP 之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。那么一条网络报文是怎么从一个容器发送到另外一个容器的呢？容器直接使用目标容器的 ip 访问，默认通过容器内部的 eth0 发送出去。

也就是说，先要找到 Node 对应宿主机的 IP 地址，将数据发送到这个宿主机的网卡，然后在宿主机上将相应的数据转发到具体的 docker0 上。Pod 的地址是与 docker0（cni0） 在同一个网段的，我们知道 docker0（cni0） 网段与宿主机网卡是两个完全不同的 IP 网段，并且不同 Node 之间的通信只能通过宿主机的物理网卡进行，之前提到，Kubernetes 的网络对 Pod 的地址是平面的和直达的，所以这些 Pod 的 IP 规划也很重要，不能有冲突。

由于 Kubernetes 的网络模型假定 Pod 之间使用的是对方 Pod 的实际地址进行访问，因此，一个 Pod 内部的应用程序看到的 IP 地址和端口号与集群中的其它 Pod 看到的是一样的，都是 Pod 实际分配的 IP 地址。但是与单纯的交换机不同，交换机只是一个二层设备，对于接受到的报文，要么转发，要么丢弃。一个 veth 设备对是由两个虚拟网络接口组成的，它们成对出现，一端连接到一个命名空间中，另一端连接到另一个命名空间中，可以通过这个设备对实现两个命名空间之间的通信。

etcd 是一个高可用的分布式键值存储系统，被用来存储 Kubernetes 集群中的所有配置数据和状态信息。etcd 具有高可用、强一致性和快速响应等特性，可以保证 Kubernetes 集群的数据可靠性和一致性。Raft 是一种更为简单方便易于理解的分布式算法，主要解决了分布式中的数据一致性问题。分布式系统的数据一致性问题是指在分布式系统中，多个节点之间共享数据时可能会因为网络延迟、节点故障等原因导致数据不一致的情况。

为了支持集群的水平扩展和高可用性，Kubernetes 抽象出了 Service 的概念。Service 是对一组 Pod 的抽象，它会根据访问策略（如负载均衡策略）来访问这组 Pod。Service 提供了一个稳定的 IP 地址和DNS 名称，这使得服务可以被客户端通过这些统一的方式访问，服务会将请求转发到后端的 Pod 上。在很多情况下，Service 只是一个概念，而真正将 Service 的作用落实的是它背后的 kube-proxy 服务进程。

在 Kubernetes 集群中，每个节点（Node）上都会运行一个 kubelet 服务进程。kubelet 是 Kubernetes 中的一个重要组件，用于管理该节点上的 Pod 和容器。kubelet 进程会从 Kubernetes 的 Master 节点上接收指令，执行相应的任务，如创建、启动、停止、销毁 Pod 和容器等。同时，kubelet 会定期向 Master 节点汇报该节点上的资源使用情况和容器状态等信息，以供集群管理者进行资源调度和容器运维等工作。

Kubernetes Scheduler 是 Kubernetes 集群中的一个核心组件，用于将 Pod 调度到适合的 Node 上运行。在 Kubernetes 中，Pod 是最小的可调度单元，而 Node 则是运行 Pod 的物理或虚拟机器。调度器负责决定每个 Pod 应该在哪个 Node 上运行，以最大程度地利用集群资源，并满足用户定义的调度策略。Kubernetes Scheduler 通过调度算法和策略来实现 Pod 的调度。

一般来说，智能系统和自动系统通常会通过一个“操作系统”不断修正系统的工作状态。在 Kubernetes 集群中，每个 Controller 都是这样的一个“操作系统”，

Kubernetes API Server（API Server）是 Kubernetes 的核心组件之一，负责暴露 Kubernetes API 给用户和客户端，接收和处理来自客户端的请求，并将其存储到 etcd 中。Kubernetes API Server 主要作用是提供 Kubernetes 各类资源对象（如 Pod、Deployment、Service等）的增、删、改、查及 Watch 等 HTTP REST 接口，是集群内各个功能模块直接数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。

这个例子定义了两个路由规则，一个是将来自的请求路由到名为 foo-service 的 Service 上，另一个是将来自的请求路由到名为 bar-service 的 Service 上。其中，pathType 表示路径匹配类型，支持两种类型：Prefix 和 Exact。如果使用 Prefix，则请求的路径必须以指定的路径前缀开始；如果使用 Exact，则请求的路径必须与指定的路径完全匹配。1.规则相关设置在 Ingress 中，可以通过 rules 字段来定义请求路由规则。

自定义 Service 控制器的实现方式包括：通过自定义 Kubernetes 控制器来实现自定义负载均衡算法，控制器会监听 Kubernetes 中的 Service 和 Endpoint 资源，然后根据自定义算法动态地更新负载均衡策略。使用第三方负载均衡器：可以通过将第三方负载均衡器（如 Nginx、HAProxy 等）部署到 Kubernetes 集群中，并使用 Kubernetes 中的 ExternalName Service 来将请求路由到这些负载均衡器上。

在 Kubernetes 中，kube-proxy 通过 iptables 模式实现 Service 的负载均衡功能。kube-proxy 会在每个节点上维护一个 iptables 规则集，这个规则集会根据 Service 和 Endpoint 的信息动态地生成和更新。当请求到达节点时，iptables 会根据规则集中的负载均衡策略将请求转发到相应的 Pod。说的直白点，

在 Kubernetes 中，Service 是一种用来暴露一组 Pod 的网络服务的抽象机制，可以通过 Service 作为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。更详细地说，Service 是一个抽象的逻辑实体，它定义了一组 Pod 的逻辑集合以及访问它们的策略。Service 提供了一个稳定的 IP 地址和DNS 名称，这使得服务可以被客户端通过这些统一的方式访问。

出于各种原因，对于运行各种负载（如：Deployment、StatefulSet、DeamonSet）的中等规模或大规模集群，我们需要尽可能提高其资源利用率。一种常见的提高资源利用率的方法是采用优先级方案，即为不同类型的负载分配不同的优先级。同时，允许所有负载所需的资源总量超过集群可提供的资源。在资源不足的情况下，系统可以根据优先级释放一些不重要的负载（优先级最低的），以保障最重要的负载能够获取足够的资源稳定运行。

假如我们有一种场景，我们希望某些节点是专用节点，比如 Kubernetes master 节点，就不希望业务应用 Pod 调度过来。或者防止一些非关键的 Pod 占用一些特殊的节点资源，如大页内存。这个时候我们就希望这些节点有一些“污点”，这样专用 Pod 能容忍这些污点，就可以实现调度，不能容忍的，不让其调度过来。为了实现这一场景，Kubernetes 涉及到污点与容忍（Taints 和 Tolerations）。

在实际的生产环境中有一类特殊的 Pod 调度需求：存在某些相互依赖、频繁调用的 Pod，它们需要被尽可能地部署在同一个 Node 节点、机架、机房、网段内，这就是 Pod 之间的亲和性；反之，出于避免竞争或者容错的需求，我们也可能使某些 Pod 尽可能地远离某些特定的 Pod，这就是 Pod 之间的反亲和性和互斥性在 Kubernetes 中，PodAffinity 用于指定一组 Pod 如何与其他 Pod 互相关联。

Node Affinity 是 Kubernetes 中的一种调度机制，允许 Pod 在调度到节点时对节点进行约束和限制。通过使用 Node Affinity，可以控制 Pod 在哪些节点上可以运行或不能运行，从而优化应用程序的性能和资源使用情况。Node Affinity 可以根据节点的标签或其他属性，将 Pod 调度到满足特定需求的节点上。例如，可以将某些应用程序调度到具有 GPU 资源的节点上，以获得更好的性能。

我们来做一个小实验：我们发现容器在 Master 节点被创建出来，说明 Pod 被调度到了 Master 节点上。但是我们前面内容说过，一般 Master 节点作为管理节点，不直接运行应用。Deployment 创建出来，Pod 的调度如果不加以人为干预，调度器会选择一个资源更充足的节点进行调度。那问题来了，我就需要控制 Pod 的调度，让业务应用去工作节点（Node）运行，有没有方法呢？那么我们从这章节开始，就要讲资源的调度了。Label 与 SelectorNode 亲和性。

前面我们学习了 Deployment、 StatefulSet、DeamonSet、Job，明白了 Kubernetes 为了帮助我们更好的管理 Pod，提供了一系列好用的工具。但是还远远不止于此，以上工具还需要我们手动设置 replicas 副本数量。我们来想象一种场景，我们服务已经正常上线了，运行良好。但是节假日流量突升，我们不得不扩容副本以应对流量；然后节假日一过，我们又得手动缩容。听起来好像有点麻烦，有没有更方便的方法，让系统自动感知流量突升并自动增加副本数量？

我们来假设一种场景，我们集群有很多个工作节点，我们需要在每一个工作节点上都运行一个监控程序，用以收集节点状态、日志等。那么如果使用 Deployment、StatefulSet，我们就得设置各自标签、污点来保证每一个副本相互隔离开，并正确调度到各个工作节点，那样真的是太麻烦了。有没有一种更为简单的方法呢？当然有，那就是 DeamonSet。我们来假设一个场景，有些任务在执行时，就是一个一次性任务，不像 Deployment 服务一直作为服务端运行。那应该如何处理呢？

上一节我们介绍了 Deployment 无状态应用，Deployment 实际上并不足以覆盖所有的应用编排问题。造成这个问题的根本原因，在于 Deployment 对应用做了一个简单化假设。它认为，一个应用的所有 Pod，是完全一样的。所以，它们互相之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Deployment 就可以通过 Pod 模板创建新的 Pod；不需要的时候，Deployment 就可以“杀掉”任意一个 Pod。但是，在实际的场景中，并不是所有的应用都可以满足这样的要求。

通过前面对 Pod 的由浅入深的了解后，我们知道了 Kubernetes 中最小的部署单元就是 Pod，Pod 确实也很方便，配置一些参数就能够有很多强大的功能，如探针检查、preStop 等。Pod 这个看似复杂的 API 对象，实际上就是对容器的进一步抽象和封装而已。说得更形象些，“容器”镜像虽然好用，但是容器这样一个“沙盒”的概念，对于描述应用来说，还是太过简单了。这就好比，集装箱固然好用，但是如果它四面都光秃秃的，吊车还怎么把这个集装箱吊起来并摆放好呢？所以，Pod 对象，其实就是容器的升级版。

本章我们分享一个 Pod 对象在 Kubernetes 中的生命周期。Pod 生命周期的变化，主要体现在 Pod API 对象的 部分，这是它除了 和 之外的第三个重要字段。其中，，就是 Pod 的当前状态，它有如下几种可能的情况：Pending：Pod 被创建，但是还没有分配到可用的节点上。Running：Pod 已经被调度到了某个节点上，并且 Pod 中的容器至少有一个正处于运行状态。Succeeded：Pod 中的所有容器都已经成功运行完毕，并且已经退出，且不会再重启。Failed：Pod 中的

安全性不同：由于 EmptyDir Volume 存储在节点上的本地存储中，因此不能保证数据的安全性，例如当节点故障时，EmptyDir Volume 中的数据可能会丢失，而 HostPath Volume 存储在宿主机的本地存储中，因此可以使用宿主机上的文件系统安全特性来保护数据。Kubernetes 支持 iSCSI 存储的挂载。EmptyDir Volume 是 Kubernetes 中一种简单的卷类型，它会在 Pod 中的某个节点上创建一个临时目录，并将该目录挂载到 Pod 中的一个或多个容器中。

Pod 是 Kubernetes 中最小的可部署的单元。Pod 可以包含一个或多个紧密关联的容器，并共享同一个网络和存储空间等资源。Pod 是 Kubernetes 中的一个抽象层，它封装了一个或多个容器，并提供了一个单一的部署单位，即 Pod，使得这些容器能够协同工作。容器：Pod 中包含一个或多个容器，每个容器都运行着一个应用程序或服务。同时每个 Pod 都有一个最基本的Pause 容器。共享存储卷：Pod 中的所有容器可以共享同一个存储卷 Volume，这样它们就可以在运行时共享数据。网络命名空间。

Minikube：是 Kubernetes 的一个轻量级的单节点版本，可在本地电脑上快速搭建一个 Kubernetes 环境，方便开发人员进行本地开发和测试。Kubectl：是 Kubernetes 的命令行工具，用于管理 Kubernetes 集群和应用程序，包括创建、更新、删除 Kubernetes 对象，查看 Kubernetes 对象状态等。Kubelet：是 Kubernetes 的一个核心组件，主要用于管理和控制运行在节点上的 Pod，它会负责启动和停止容器，并监控 Pod 的运行状态。

现有的大量镜像该怎么办？于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。面对 Kubernetes“咄咄逼人”的架势，Docker 是看在眼里痛在心里，虽然有苦心经营了多年的社区和用户群，但公司的体量太小，实在是没有足够的实力与大公司相抗衡。

意味着在每 100 ms 的时间里，被该控制组限制的进程只能使用 20 ms 的 CPU 时间，也就是说这个进程只能使用到 20% 的 CPU 带宽。这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 1000。它执行了一个死循环，可以把计算机的 CPU 吃到 100%，根据它的输出，我们可以看到这个脚本在后台运行的进程号（PID）是 33974。

这种网络类型适用于一些特殊场景，如需要运行一些网络隔离的容器，或者容器只需要本地访问或者与其他容器通过共享数据卷进行通信，而不需要进行网络通信。需要注意的是，使用 None 网络时，容器将无法使用 ping 等网络命令进行网络测试，也无法使用 apt-get 等命令从网络上下载文件。），可以将数据卷挂载到容器中，从而使容器能够访问该目录中的数据。在 Docker 中，Bridge 网络模式是最常用的网络模式之一，它使用Linux的 Bridge 模块来为 Docker 容器提供网络隔离和通信。

FROM 这个镜像的妈妈是谁？（指定基础镜像）MAINTAINER 告诉别人，谁负责养它？（指定维护者信息，可以没有）RUN 你想让它干啥（在命令前面加上RUN即可）ADD 给它点创业资金（COPY文件，会自动解压）WORKDIR 我是cd,今天刚化了妆（设置当前工作目录）VOLUME 给它一个存放行李的地方（设置卷，挂载主机目录）EXPOSE 它要打开的门是啥（指定对外的端口）CMD 奔跑吧，兄弟！（指定容器启动后的要干的事情）COPY 复制文件ENV 环境变量。

Docker 将一个 Docker 镜像分解成多个不同的层（Layer），每个层都是只读的文件系统，层与层之间是相互独立的。这种分层的设计可以提高 Docker 镜像的复用性和共享性。每个 Docker 镜像都是由一个或多个只读层（镜像层）和一个可读写层（容器层）组成。只读层是可以在不同镜像之间共享的，因此 Docker 的镜像可以通过利用这种分层的设计来尽可能地减少重复的数据存储，提高镜像的复用性。同时，Docker 镜像分层的设计还可以方便地管理和维护镜像。

Docker 是一种容器化技术，它可以将应用程序及其依赖项封装为一个独立的容器中。将应用对应的系统配置和SDK依赖打包成一个镜像文件，在环境上直接通过镜像创建容器并运行，简化了应用程序的部署过程；提供了轻量级的虚拟化，只需要将应用对应的系统配置和SDK依赖打包成一个镜像文件，而不需要一个完整的操作系统，避免了虚拟机带来的额外开销；可以更好地管理不同应用程序之间的依赖关系和版本，因为镜像可以有不同的版本，通过来管理；更容易迁移和扩展应用程序，这就是镜像文件的好处；

本章讲解了快速安装 k8s+docker，为后面的学习搭建好环境，搭建过程中遇到的坑都进行了相应的解决办法，好了，后面见。

NAT模式下的虚拟系统的TCP/IP配置信息是由 VMnet8(NAT)虚拟网络的 DHCPserver 提供的，无法进行手工改动，因此虚拟系统也就无法和本局域网中的其它真实主机进行通讯。在单个Windows应用程序中，它提供了大量功能，这些功能是为程序员，网站管理员，IT管理员以及需要以更简单的方式处理远程作业的所有用户量身定制的。ok，但是我们学习呢，要搭建一个IaaS成本太高了，一是没那么多资源，二是安装费时间，所以只要能创建虚拟机，那么就能满足我们的学习需求，快速动手实践起来。

Kubernetes，简称 K8s，是一个开源的、用于管理云平台中多个主机上的容器化的应用平台，提供了应用部署，规划，更新，维护的一种机制**。其中容器虚拟化技术以 Docker 为首，Docker 是基于 Go 语言实现的云开源项目，Docker 的主要目标是“Build，Ship and Run Any App,Anywhere”，也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的 APP（可以是一个 WEB 应用或数据库应用等等）及其运行环境能够做到“一次镜像，处处运行”。

云计算是一种通过计算机网络以服务的方式提供动态可伸缩的虚拟化资源的计算模式。按照服务层次分为IaaS、PaaS和SaaS三个层次；按照部署方式可以分成公有云、私有云和混合云。这里有两个点注意，一是云计算通过虚拟化技术实现，表现为虚拟化资源；二是云计算是一种按量付费的模式。这里再通俗解释一下，比如一台硬件服务器，有内存20G、硬盘500G、CPU 12个，传统方式得整台租用。但是我可能用不了那么多资源，于是有人通过虚拟化技术将内存、硬盘、CPU抽象出资源池，这个过程叫资源虚拟化。