zgt_certificate的博客

Kubernetes中的网络策略（NetworkPolicies）允许控制特定应用程序在TCP、UDP协议下的IP地址或端口级别的流量。这些策略是以应用程序为中心的，用于指定如何允许Pod通过网络与其他网络“实体”（即不同的端点和服务）进行通信。网络策略主要适用于有Pod参与的连接。在定义基于Pod或命名空间的网络策略时，可以使用选择器来指定允许哪些流量进出选定的Pod。通过上述方法和策略，Kubernetes网络策略可以有效地管理和控制Pod之间及其与外部世界的网络流量，确保集群内的安全和高效通信。

Node对象跟踪节点的资源容量信息。：Kubelet定期从API Server获取Pod定义，并调用容器运行时（如Docker、containerd）来创建和管理容器，同时监控它们的运行状态。：Kubelet是每个节点上的代理，负责与控制平面通信，执行分配给该节点的任务，并管理Pod和容器的生命周期。通过这些机制和组件，Kubernetes能够有效管理和调度集群中的节点，确保容器化应用的高可用性和资源优化。：运行在节点上的所有容器，常用的容器运行时包括Docker、containerd、CRI-O等。

API Server是Kubernetes的入口点，负责处理RESTful API请求，所有的操作请求都通过它进行。：确保部署的Pod数量、状态、配置等达到预期，如ReplicaSet控制器保证副本数量，Node控制器监控节点状态等。：控制器是一种循环机制，不断监视集群的实际状态和期望状态之间的差异，并通过API Server做出相应调整。：在部署新的应用程序时，确保Pod能够被调度到适合的节点，以满足资源需求和性能要求。：Kubelet是运行在每个节点上的代理，负责管理节点上的Pod和容器。

Docker Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过 Compose，您可以使用 YAML 文件来配置应用程序需要的所有服务，然后，使用一个命令，就可以从 YAML 文件配置中创建并启动所有服务。这个配置文件创建了一个简单的应用程序，其中包含一个 Nginx 服务器和一个 MySQL 数据库。文件定义构成应用程序的服务，这样它们可以在隔离环境中一起运行。将主机的 8080 端口映射到容器的 80 端口。的卷，用于存储 MySQL 数据库的数据。

在新主机上首次安装 Docker Engine-Community 之前，需要设置 Docker 仓库。首先，安装所需的软件包。这条命令会自动下载并安装 Docker，同时使用阿里云的镜像源以加快下载速度。安装最新版的 Docker Engine-Community 和。），需要先卸载它们以及相关的依赖项。安装 Docker Engine-Community。如果系统中已经安装了旧版本的 Docker（即。1. 使用官方安装脚本自动安装。设置 Docker 仓库。3. 卸载 Docker。

容器进程可以跟主机 root 进程一样可以打开低范围的端口，可以访问本地网络服务比如 D-bus，还可以让容器做一些影响整个主机系统的事情，比如重启主机。：让 Docker 将新建容器的进程放到一个已有容器的网络堆栈中，新容器进程有自己的文件系统、进程列表和资源限制，但会和已有容器共享 IP 地址和端口等网络资源，两者进程可以直接通过 lo 环回接口通信。当容器结束后，Docker 会清空容器，容器内的 eth0 会随网络命名空间一起被清除，A 接口也被自动从 docker0 卸载。

然后同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 名字空间间的进程间交互，因此需要在 IPC 资源申请时加入名字空间信息，每个 IPC 资源有一个唯一的 32 位 id。mnt 名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间中的进程看到的文件目录就被隔离开了。同 chroot 不同，每个名字空间中的容器在 /proc/mounts 的信息只包含所在名字空间的 mount point。在 Linux 内核中，名字空间是一种强大的特性。

容器的链接（linking）系统是除了端口映射外，另一种在容器中应用交互的方式。该系统会在源和接收容器之间创建一个隧道，使接收容器可以看到源容器指定的信息。环境变量和 /etc/hosts 文件。参数可以让容器之间安全地进行交互。

这里，主机的 49155 端口被映射到了容器的 5000 端口，可以通过访问主机的 49155 端口来访问容器内的 web 应用。在 Docker 容器中运行网络应用时，可以通过端口映射将容器内的端口暴露给外部，从而让外部访问这些应用。格式可以将 localhost 的任意端口到容器的 5000 端口，本地主机会自动分配一个端口。标志会随机映射一个 49000-49900 范围内的端口到容器内开放的网络端口。标志允许指定需要映射的端口，并且在一个指定端口上只能绑定一个容器。5. 映射到指定地址的任意端口。

数据卷容器是一个普通的容器，专门用于提供数据卷供其他容器挂载。它的主要用途是将数据卷的生命周期与应用容器分离，使数据可以在容器之间共享和持久化。数据卷容器实际上是一个专门用于数据存储的普通容器，它不会自动删除，除非所有挂载该数据卷的容器都删除。使用数据卷容器进行备份和恢复时，确保目标容器已经挂载了正确的数据卷，并且备份文件路径正确。如果要恢复数据到一个容器，首先创建一个带有数据卷的容器。容器卷的容器，并从本地主机挂载当前目录的。容器中的数据卷挂载到这两个容器中。数据卷挂载到该容器中。

可能会造成文件 inode 的改变，从 Docker 1.1.0 开始，这会导致报错。因此，最简单的办法是直接挂载文件的父目录。：卷会一直存在，直到没有容器使用它，类似于 Linux 下对目录或文件进行挂载。：对数据卷的修改会立即生效，并且数据卷的更新不会影响容器。标志也可以用于将单个文件从主机挂载到容器中。注意：直接挂载一个文件，许多文件编辑工具（如。标志也可以将本地主机的目录挂载到容器中去。标志来创建一个数据卷并将其挂载到容器里。文件中，这样可以记录在容器中输入的命令。的数据卷，并挂载到名为。

通过这些命令，可以精细地控制Docker网络配置，包括在启动Docker服务时配置网络参数，以及在启动容器时指定DNS、主机名和端口映射等设置。这些命令可以灵活地管理和调整容器网络，以满足不同的应用需求。在Docker中配置网络，包括通过Linux命令来调整、补充甚至替换Docker默认的网络配置。这些命令选项只有在Docker服务启动时才能配置，无法在运行时生效。这些命令既可以在启动Docker服务时指定，也可以在启动容器时通过。2. 可以在Docker服务启动时或容器启动时指定的命令。

每个容器都有一个独立的网络接口（eth0），连接到docker0网桥，通过共享一个私有网段，实现了一个虚拟局域网。veth pair中的一个接口在容器内部，命名为eth0，另一个接口在主机并连接到docker0网桥，名称以veth开头。: 如果容器A的eth0接口发送一个数据包，该数据包通过vethXX接口传输到docker0网桥，docker0网桥再将其转发到另一个容器B的vethYY接口，最终到达容器B的eth0接口。Docker网络的工作原理，特别是docker0网桥和veth pair接口的使用。

当我们需要再创建一个新的镜像在其上安装更多软件时，只需增加新的层，基础的Ubuntu和Python层可以被复用。每一层都是只读的，层与层之间叠加形成最终的镜像。: 获取镜像是指从镜像仓库（如Docker Hub）下载镜像到本地环境。: 创建镜像指的是通过Dockerfile或其他方式生成一个新的镜像。: 存出镜像是指将镜像保存为文件，载入镜像是指从文件加载镜像。: 修改已有镜像是指基于现有镜像进行更改并创建一个新的镜像。: 运行一个已有的镜像，进行修改后再提交为新镜像，如。命令查看当前所有本地的镜像列表。

Docker 支持多种架构，包括 x86_64（或 amd64），armhf，arm64，s390x（IBM Z），和 ppc64le（IBM Power）。更新APT包索引，然后安装Docker Engine，Docker CLI和Containerd。在安装最新版本的 Docker 之前，建议先卸载旧版本。安装完成后，启动Docker服务并运行一个测试容器来验证安装是否成功。为了确保下载的软件包的安全性，需要添加Docker的官方GPG密钥。在安装Docker之前，需要确保APT包索引是最新的。

通过客户端工具与守护进程的交互，用户可以方便地管理容器和镜像，并利用注册表进行镜像的存储和分发。Docker的架构可以分为三个主要部分：客户端（Clients）、主机（Hosts）和注册表（Registries）。例如，图中的repository 1包含镜像1和镜像2，repository 2包含镜像3和镜像4。（命令行界面）：这是用户最常用的工具，通过命令行执行各种Docker命令，如构建、运行和管理容器。：容器的模板，是不可变的文件系统，包含应用程序运行所需的所有内容。

复制指定的src路径下的内容到镜像中的dest路径下，src可以为url会自动下载，可以为tar文件，会自动解压。如果在Dockerfile中定义了同名的ARG变量，则命令行传递的值会覆盖Dockerfile中定义的默认值。：指定镜像构建使用的参数（如版本号等），可以在build的时候，使用--build-args改变。如果用户在构建时传递了未在Dockerfile中定义的构建参数，构建过程会发出警告，但不会出错。：复制本地主机的src路径下的内容到镜像中的dest路径下，但不会自动解压等。

*managed-nfs-storage.storageclass.storage.k8s.io/requests.storage: "5G"**：特定存储类别下的PVC请求的存储总量不超过5GiB。**requests.storage: "10G"**：所有持久卷声明（PVC）请求的存储总量不超过10GiB。**requests.cpu: "4"**：所有Pod请求的CPU总和不超过4个核心。**limits.cpu: "6"**：所有Pod的CPU限制总和不超过6个核心。：资源配额所属的命名空间。

它的主要作用是限制命名空间中资源的使用量，以防止某个命名空间独占过多的集群资源。：限制命名空间内Pod、Deployment、StatefulSet、Service、Secret、ConfigMap、Job、CronJob等资源的数量。：限制命名空间内所有Pod的CPU和内存请求总量，和requests.cpu/memory一样。：所有Pod上限资源配置总量不超过该值（所有非终止状态的Pod）。：所有Pod请求资源配置总量不超过该值（所有非终止状态的Pod）。：限制特定存储类别下所有持久卷声明的数量。

准入控制器Webhook是准入控制插件的一种，用于拦截所有向APIServer发送的请求，并且可以修改请求或拒绝请求。请求从kubectl发出，经过API Server的Admission Controllers处理。通过这些控制器，可以在资源被持久化之前进行各种校验和修改，以确保资源符合安全和策略要求。提供灵活的插件模式，在Kubernetes资源持久化之前进行校验、修改等操作。：修改资源，理论上可以监听并修改任何经过APIServer处理的请求。：镜像策略，主要验证镜像字段是否满足条件。

当default SA创建时，会自动创建一个default-token-xxx的secret，并自动关联到SA。当创建namespace时，会自动创建一个名为default的SA，这个SA没有绑定任何权限。无需单独为某个用户创建权限，统一为这个组名进行授权，所有的用户都可以以组的身份访问资源。测试：只要O字段都是dev，这些用户持有的kubeconfig文件都拥有相同的权限。Kubernetes的默认授权策略，动态配置策略（修改即时生效）。通过RBAC可以实现对不同用户或服务账号的精细化权限控制。

客户想要访问K8s集群的API Server，一般需要证书、Token或用户名+密码。实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查。通过配置和管理准入控制器，可以确保所有进入Kubernetes集群的请求都经过严格的审查和验证。最后一步是准入控制插件，这些插件可以对即将持久化的资源进行检查、修改或拒绝。鉴权通过后，API Server会检查该用户是否有权限执行所请求的操作。经过上述三步之后，请求才会被处理，对应的操作才会在集群中执行。

它提供了多种预定义的功能集，称为 Chisels，用于分析特定的场景。Chisels 是一组预定义的功能集，用来分析特定的场景。：显示特定容器的CPU使用情况，可以按容器名称或ID查看。：显示读写磁盘文件最多的进程，特别是etcd进程。：分别显示CPU、网络、文件资源使用最高的容器。：统计进程打开的文件描述符数量，前10名。：列出所有打开的文件和对应的进程。：统计连接的IP地址，前10名。：显示磁盘读写活动最频繁的进程。：显示CPU使用率最高的进程。：显示网络活动最频繁的进程。：按端口统计传输的字节数。

Kubernetes审计策略文件包含一系列规则，描述了记录日志的级别，采集哪些日志，不采集哪些日志。适用于需要基本审计记录，但不需要深入细节的场景。包括元数据和请求正文，但不包括响应正文。：需要完整记录请求和响应的场景，适用于全面审计需求。：需要详细记录请求内容，但对响应内容不敏感的场景。：在不需要记录任何日志的情况下使用。：审计日志最大可存储多少个日志文件。：单个审计日志最大大小，单位为MB。：审计日志保留的最大天数。：不为事件创建日志条目。：审计日志策略文件路径。：审计日志输出文件路径。

通过合理配置网络策略，可以增强集群的安全性，确保不同命名空间和应用之间的通信符合预期的安全要求。这个策略将禁止所有Pod的入站和出站流量，确保该命名空间内的Pod无法与外部通信。这个策略允许其他命名空间内的Pod访问指定命名空间内某一应用的Pod。定义允许访问的来源，可以是 IP 段、命名空间或 Pod 标签。这个策略将禁止其他命名空间内的Pod访问指定命名空间内的Pod。这个策略将只允许特定命名空间中的应用访问该命名空间内的Pod。: 目标 Pod，通过标签选择器确定应用策略的 Pod。

以上四种调度方式在Kubernetes中广泛使用，可以满足不同场景下Pod的调度需求。：通过Taint使Node拒绝特定Pod的运行，通过Toleration使Pod可以容忍特定的Taint。：自动部署一个容器应用的多个副本，并持续监控和管理副本数量，确保在集群内始终维持用户指定的副本数量。：通过Node的标签和Pod的nodeSelector属性相匹配，将Pod调度到特定的Node上。：亲和性调度机制，通过亲和性规则将Pod调度到符合条件的Node上。：效果，表示允许调度到带有该Taint的节点。

如果日志量不大且可以输出到stdout和stderr，可以选择第一种方式。当容器日志可以输出到某些文件时，可以通过一个Sidecar容器来读取这些日志文件，并将其重定向到stdout和stderr，然后再使用第一种方式将日志收集到Fluentd。这种方式是将Fluentd容器直接部署在Pod中，通过Sidecar容器将应用程序的日志直接发送到远端存储中，如Elasticsearch。这个示例通过一个Sidecar容器读取应用程序的日志文件，并将日志重新输出到Fluentd容器的stdout和stderr。

在Kubernetes（K8s）中，Service和Ingress是两种不同的资源对象，它们的主要作用是为Pod提供统一的访问接口，并实现负载均衡和外部访问。一个电商网站的前端服务可以定义一个Service，通过LoadBalancer类型暴露给外部用户，这样用户访问这个前端服务时，实际请求会被分配到多个后端Pod上，实现负载均衡。通过定义一个Nginx Ingress控制器，可以将不同的URL路径路由到不同的服务，实现类似于API网关的功能。）路由到不同的Service，实现统一入口和管理。

kubelet（节点代理）在每个工作节点上监视etcd中的变化，并在选定的节点上创建Pod，拉取容器镜像并启动容器。，那么所有具有该标签的Pod都会被包含在这个Service的负载均衡范围内，用户访问Service的IP地址时，请求会被转发到这些Pod上。在K8s集群中，容器被封装在Pod中。文件中定义了一个Nginx容器，那么K8s会在指定的节点上启动这个Nginx容器，并将其封装在一个Pod中运行。命令时，K8s会根据mypod.yaml文件中定义的内容创建一个Pod，并将其调度到合适的节点上运行。

也是基于应用层的负载均衡器，特别擅长于处理高并发的 HTTP 和 TCP 请求，功能强大且灵活，提供丰富的状态监测和健康检查功能。：在状态监测和健康检查方面，HAProxy 功能更为丰富，支持端口、URL、脚本等多种状态检测方式，能够更好地保障服务的稳定性。：功能强大，能提供非常细粒度的控制和丰富的状态监测功能，适用于需要精确控制和高可靠性的场景，但整体性能略低于 LVS。：作为四层负载均衡，其状态监测功能相对简单，但性能非常高，能处理大规模的并发连接，适合在内网中的大规模部署。

一个大型电商网站使用七层负载均衡器，根据用户请求的 URL 将不同类型的请求（如静态资源请求、动态页面请求）分配到不同的服务器集群，以优化网站性能和用户体验。：七层负载均衡器在应用层进行操作，可以解析应用层的内容，根据具体的请求信息（如 HTTP 头、URL 路径、Cookie 等）进行更加精细的负载均衡。：一个在线游戏服务器集群，使用四层负载均衡器根据玩家的 IP 地址和端口号分配到不同的游戏服务器，确保所有服务器的负载均衡。：功能强大，能够进行复杂的调度决策，适用于需要根据应用层数据进行调度的场景。

用户的浏览器带有名为 "session_id" 的 cookie，HAProxy 根据这个 cookie 值分配请求，保证同一用户的请求总是命中同一服务器。：有三个服务器 A、B、C，第一请求发送给 A，第二请求发送给 B，第三请求发送给 C，第四请求再次发送给 A，如此循环。：服务器 A 处理了 5 个请求，服务器 B 处理了 3 个请求，服务器 C 处理了 1 个请求，新请求会被分配给 C。：根据请求头中的 "User-Agent" 字段，将不同类型的用户请求分配到不同的服务器。

HAProxy 支持客户端的 keepalive 功能，减少客户端与 HAProxy 的多次握手导致的资源浪费，让多个请求在一个 TCP 连接中完成。HAProxy 提供更好的统计数据接口，其中 Web 界面显示后端集群中各个服务器的接收、发送、拒绝、错误等数据的统计信息。基于源的粘性，类似 Nginx 的 ip_hash 功能，把来自同一客户端的请求在一定时间内始终调度到上游的同一服务器。详细的健康状态检测，Web 接口中有关于对上游服务器的健康检测状态，并提供了一定的管理功能。

cgroup和Kubernetes中的namespace虽然都是用于资源隔离和管理，但它们的应用层级和具体实现有所不同。：两者都用于对资源的使用进行管理和控制，cgroup控制系统资源的分配和限制，namespace控制Kubernetes资源的组织和分配。Kubernetes的namespace是一种用于将集群中的资源（如pod、服务等）进行逻辑分组和隔离的机制。：cgroup和namespace都提供了一种资源隔离的机制，前者针对系统资源，后者针对Kubernetes资源。

每个 Pod 都有一个唯一的 IP 地址（例如，Node 1 上的 Pod 的 IP 为 172.16.3.2 和 172.16.3.3，Node 2 上的 Pod 的 IP 为 172.16.4.2 和 172.16.4.3）。当 Node 1 上的 Pod 1（IP 172.16.3.2）需要与 Node 2 上的 Pod 2（IP 172.16.4.2）通信时，数据包从 Pod 1 的 eth0 发出，通过 veth1 发送到 Node 1 的网桥。

不同的 CNI 插件（如 Flannel 和 Calico）提供了不同的功能和特性，用户可以根据需求选择合适的插件进行部署和配置。通过正确配置 CNI 插件，可以确保 Kubernetes 集群中的 Pod 和节点之间实现高效、可靠的网络通信。Calico 除了提供基本的网络功能外，还提供了更高级的网络策略管理功能，可以通过定义 NetworkPolicy 来控制 Pod 之间的通信。即收到的数据包的源 IP 是发送数据包的 Pod 的 IP。不同的插件实现不同的网络功能和特性。验证网络配置是否生效。

云原生技术架构通过微服务、容器化和持续集成/持续交付等技术手段，提供了高效、灵活和可扩展的应用开发和部署模式。：利用容器技术（如Docker）将应用及其依赖打包成一个自包含的单元，确保应用可以在任何有容器运行环境的地方部署。每个应用程序在不同的部署环境（如开发、测试、生产环境）中使用相同的代码库。：云原生系统广泛使用声明式API来实现自动化和编排，API定义了服务的接口和行为，而不涉及具体的实现细节。：容器化技术是云原生应用的基础，容器不仅提供了轻量级的隔离环境，还可以快速启动和停止，提高资源利用率。

通过容器化技术、微服务架构和自动化工具，云原生能够更好地满足现代应用的需求，提高系统的可靠性和可维护性。在实际应用中，云原生能够帮助企业快速响应业务需求变化，节省成本，提升用户体验，具有广泛的应用前景。云原生是一种设计和构建应用程序的方法，旨在充分利用云计算的优势，以提高应用的可扩展性、灵活性和弹性。：使用代码来管理和配置基础设施，通过声明式配置文件（如Terraform、Ansible等）定义资源和环境，确保环境的一致性和可重复性。：容器镜像不可变，保证每次部署的环境一致性，减少因环境差异引起的问题。

合理使用这些部分，可以更好地管理和配置Kubernetes资源，从而实现应用的高效部署和运维。typeMeta部分包含关于对象类型的元信息，主要用于声明对象使用的API版本和对象的类型。objectMeta部分包含对象的元数据，包括对象的名称、命名空间、标签和注释等。spec部分定义了对象的期望状态，包括对象使用的镜像、副本数量、端口配置等。spec部分是最重要的部分之一，它描述了Kubernetes应该如何创建和管理这个资源。：表示这个资源的类型是Pod。：添加了一个注释，描述了这个Pod的用途。