Cyan_Jiang的博客

首先需要部署 Kafka 和 Logstash 至 Kubernetes 集群，如果企业内已经有比较成熟的技术栈，NOTES:NOTES:配置解析metadata:data:input {kafka {output {} else{需要注意文件中的一些配置：➢ input：数据来源，本次示例配置的是 Kakfa；

Kubernetes 故障排查是一个综合性很强的任务，涉及集群、节点、网络、存储、调度、应用等多个层面。通过上述的方法和命令，您可以系统地排查和解决问题。定期的监控、日志记录、自动… End …

Helm使用的包格式被称为Chart。Chart就是一个描述所有Kubernetes资源的文件集合。一个Chart用于部署一个完整的应用，例如数据库、缓存、Web服务等。本节对Chart的目录结构、主要文件和关键配置信息进行说明。

简单控制：使用和快速控制节点的调度状态。精细控制：通过taints和精确控制哪些 Pod 可以调度到哪些节点。节点维护：使用进行节点维护时优雅地清空节点上的 Pod。资源隔离：通过资源配额来限制资源使用，间接影响节点的调度行为。高级调度：通过自定义调度器和实现复杂的调度需求。

Guaranteed（保证）功能：为关键任务负载提供最严格的服务质量保障。区别：所有容器都需要设置相同的 CPU 和内存的请求和限制（即注意事项：这种 QoS 类别的 Pod 在资源紧张时最不容易被驱逐。Burstable（突发）功能：适用于需要灵活资源的应用，可以在必要时使用更多的资源。区别：至少有一个容器的requests小于limits或者不是所有的容器都设置了资源限制。注意事项：在资源竞争时，Burstable Pod 的优先级次于 Guaranteed，但高于 BestEffort。

在调度的时候 requests 比较重要，在运行时 limits 比较重要。

对命名空间的资源限制多个项目，时间长了，会有大量无用的资源pod等。限制资源使用，超过设置的资源，则不能创建。

Kubernetes集群有两种用户账号：第1种是集群内部的Service Account；第2种是外部的用户账号，可能是某个运维人员或外部应用的账号。Kubernetes并不支持常规的个人账号，但拥有被Kubernetes集群的CA证书签名的有效证书，个人用户就可被授权访问Kubernetes集群了。也是一种账号，但它并不是给Kubernetes集群的用户（系统管理员、运维人员、租户用户等）用的，而是给运行在Pod里的进程用的，它为Pod里的进程提供了必要的身份证明。

但是需要注意的是该网络策略的ingressfrom是以namespaceSelector的标签进行匹配的，并非podSelector，或者是两者的结合。因为在生产环境中，同一个Namespace下可能会有很多不同类型、不同标签的Pod，并且它们可能并不具有一个相同的标签，所以如果通过podSelector进行选择，可能会比较麻烦，因为Pod一旦创建，对其标签的修改是很不方便的（apps/v1一旦创建就不可修改）。

动态存储：StorageClass:存储类，由K8s管理员创建，用于动态PV的管理，可以链接至不同的后端存储，比如Ceph、Glusterfs等。之后对存储的请求可以指向StorageClass，然后StorageClass会自动的创建、删除PV。实现方式:https://kubernetes.io/docs/concepts/storage/storage-classes示例：2、CSI在 Kubernetes 中，PV（Persistent Volume）、PVC（Persistent Vol

PersistentVolume（PV）和Persistent Volume Claim（PVC）PV（持久卷）是对存储资源的抽象，将存储定义为一种容器应用可以使用的资源。PV由管理员创建和配置，它与存储提供商的具体实现直接相关，例如GlusterFS、iSCSI、RBD或GCE或AWS公有云提供的共享存储，通过插件式的机制进行管理，供应用访问和使用。除了EmptyDir类型的存储卷，PV的生命周期独立于使用它的Pod。PVC则是用户对存储资源的一个申请。

如果将有路径重写和没有路径重写的 Ingress 配置在一起，可能导致 NGINX Ingress 错误地将重写规则应用到所有请求路径，从而引发不可预期的行为。因此，最好分开配置或使用其他隔离机制来避免冲突。

类型匹配方式适用场景优缺点Exact完全匹配精确控制特定路径的路由控制严格，灵活性较差。Prefix匹配以指定路径为前缀的请求需要路由整个路径层级或子路径的请求常用，灵活，配置简单。Controller 决定匹配方式灵活的自定义场景或需要兼容旧版的场景依赖 Controller，兼容性差。通常情况下，Prefix是最常用的配置，可以满足绝大多数微服务和静态资源路由的需求。是定义 Ingress Controller 的资源，标识 Controller 的类型和行为。是Ingress。

每个Pod都会获取到它自己的IP地址，但是这些IP地址不总是稳定和可依赖的，这样就会导致一个问题在Kubernetes集群中，如果一组Pod(比如后端的Pod)为其他Pod(比如前端的Pod)提供服务，那么如果它们之间使用Pod的IP地址进行通信，在Pod重建后，将无法再进行连接。于是Kubernetes引用了Service这样一种抽象概念：逻辑上的一组Pod，即一种可以访问Pod的策略。这一组Pod能够被Service通过标签选择器访问到，之后就可以使用Service进行通信。

Label 是键值对，用来标识 Kubernetes 资源（如 Pod、Node、Service 等）的属性。它们并不直接影响资源的行为，但可以帮助用户快速组织、查询和操作这些资源。标签可以用于选择、过滤和分组。

K8S，黑客从pod入侵，通过pod渗透到K8S集群，被入侵会被当做矿机，被植入sidecar。注意：注入的临时容器删不掉，除非把原有pod删掉，或者重启会清空。一般下次发版，也会删除掉。生产pod不建议开启bash和sh，以及其他危险工具wget等。所以生产中尽量不用root账户，并且pod没有bash和sh。传统架构，黑客进来，提权后，会直接操作应用，危险。所以可以给pod临时注入容器，运行相关检查工具。以下命令只是1.25以下的版本需要开启。

在很多应用场景中，应用在启动之前都需要进行如下初始化操作。

Job 控制器用于管理 Pod 对象运行一次性任务，比方说我们对数据库备份，可以直接在 k8s 上启动一个 mysqldump 备份程序，也可以启动一个 pod，这个 pod 专门用来备份用的，备份结束 pod 就可以终止了，不需要重启，而是将 Pod 对象置于"Completed"(完成)状态，若容器中的进程因错误而终止，则需要按照重启策略配置确定是否重启，对于 Job 这个类型的控制器来说，需不需要重建 pod 就看任务是否完成，完成就不需要重建，没有完成就需要重建 pod。：重启策略，和Pod一致。

当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有Pod，然后下载新版本镜像并创建新的Pod。如果集群规模比较大，则这个工作变成了一个挑战，而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。Kubernetes提供了滚动升级功能来解决上述问题。

区分不同重要性的工作负载核心业务（如生产环境的应用）通常需要更高的优先级。非核心任务（如批处理、测试任务）可以分配较低优先级。确保关键服务的可用性在资源紧张或发生抢占时，确保关键服务优先获得资源。优化资源使用合理规划不同优先级的应用，避免资源被不重要的任务占用。不同等级的通常需要自定义创建，根据业务需求划分高、中、低优先级。使用为 Pod 分配合适的优先级，确保关键业务的资源调度。最后要指出一点：使用优先级抢占的调度策略可能会导致某些Pod永远无法被成功调度。

水平Pod自动缩放器HPA-Horizontal Pod AutoscalerKubernetes从1.1版本开始，新增了名为。

需要注意的是，以上拓扑域是由Kubernetes自己维护的，在Node节点初始化时，controller-manager会为Node打上许多标签，比如kubernetes.io/hostname这个标签的值就会被设置为Node节点的hostname。的意思是：如果一个Pod所在的节点在Pod运行期间标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label的变化，该Pod能继续在该节点上运行。：硬亲和力，即支持必须部要在指定的节点上，也支持必须不部署在指定的节点上。

NodeAffinity节点亲和性，是在Pod上定义的一种属性，使得Pod能够被调度到某些Node上运行（优先选择或强制要求）。Taint则正好相反，它让Node拒绝Pod的运行。简单地说，被标记为Taint的节点就是存在问题的节点，比如磁盘要满、资源不足、存在安全隐患要进行升级维护，希望新的Pod不会被调度过来，但被标记为Taint的节点并非故障节点，仍是有效的工作节点，所以仍需将某些Pod调度到这些节点上时，可以通过使用Toleration属性来实现。

在 Kubernetes 中，nodeName 是 Pod 规范 (spec) 的一个字段，用于指定 Pod 应该调度到的特定节点上。它是一个硬性要求（binding），当设置了 nodeName 后，Kubernetes 不会再通过调度器去决定这个 Pod 的节点，而是直接在指定的节点上运行。基本字段定义查看位置跳过调度器：设置 nodeName 后，调度器 (kube-scheduler) 将不会处理这个 Pod 的调度过程，而是直接将 Pod 分配到指定节点。

Pod的逻辑概念在容器之上，Kubernetes在成功创建Pod之后，会为Pod和容器设置一些额外的信息，例如Pod级别的Pod名称、Pod IP、Node IP、Label、Annotation、容器级别的资源限制等。在很多应用场景中，这些信息对容器内的应用来说都很有用，例如使用Pod名称作为日志记录的一个字段用于标识日志来源。为了在容器内获取Pod级别的这些信息，Kubernetes提供了Downward API机制来将Pod和容器的某些元数据信息注入容器环境内，供容器应用方便地使用。

要使用卷 Pod需要通过.spec.volumes 字段指定为 Pod 提供的卷，以及使用.spec.containers.volumeMounts 字段指定卷挂载的目录。从容器中的进程可以看到由 Docker 镜像和卷组成的文件系统视图，卷无法挂载其他卷或具有到其他卷的硬链接，Pod 中的每个 Container 必须独立指定每个卷的挂载位置。​ Container（容器）中的磁盘文件是短暂的，当容器崩溃时，kubelet 会重新启动容器，但最初的文件将丢失，Container 会以最干净的状态启动。

应用部署的一个最佳实践是将应用所需的配置信息与程序分离，这样可以使应用程序被更好地复用，通过不同的配置也能实现更灵活的功能。将应用打包为容器镜像后，可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入，但在大规模容器集群的环境中，对多个容器进行不同的配置将变得非常复杂。配置管理问题风险：配置文件写在代码里，管理不方便，且有风险。配置文件分离，是主要作用，独立配置文件，管理和操作都方便。如果有热加载，变更配置文件，不需要影响pod。ConfigMap用于明文配置文件，redis文件等。Secret用于

主要用于管理有状态服务应用程序的工作负载API对象。比如在生产环境中，可以部署ElasticSearch集群、MongoDB集群或者需要持久化的RabbitMQ集群、Redis集群、Kafka集群和ZooKeeper集群等。和Deployment类似，一个StatefulSet也同样管理着基于相同容器规范的Pod。不同的是，StatefulSet为每个Pod维护了一个粘性标识。

1、Pod 是由一组紧耦合的容器组成的容器组，当然目前最流行的就是 Docker、containerd、podman容器，Pod 就可以作为 1 或者多个容器的载体。2、Pod 中的所用容器会被一致调度、同节点部署，并且在一个“共享环境”中运行。Pod 想成一个车： 车里面好多座位，每个座位都坐不同的人，每个座位想成是一个容器，这里的“共享环境”包括以下几点：3、有些容器需要紧密联系，需要一起工作。Pod 提供了比容器更高层次的抽象， Pod 中的所有容器使用同一个网络的 namespace，即相同的 IP

Kubernetes中的基本概念和术语大多是围绕资源对象（Resource Object）来说的，而资源对象在总体上可分为以下两类。（1）某种资源的对象，例如节点（Node）、Pod、服务（Service）、存储（Volume）。（2）与资源对象相关的事物与动作，例如标签（Label）、注解（Annotation）、命名空间（Namespace）、部署（Deployment）、HPA、PVC。

标量就是简单的值，既可以是字符串、布尔值，也可以是数字。例如，name: my-container 中的 my-container 就是一个字符串标量，而 replicas: 3 中的 3 是一个整数标量。这里 apiVersion、kind、metadata 是键，后面的值（如 v1、Pod）是对应的值。这里 containers 是一个列表，包含了两个容器对象，每个容器对象又是一个键值对的集合。成功的pod用logs查看，不成功的pod用describe。列表表示多个值的集合，通常在 YAML 中用。

Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master上。通常通过命令行工具kubectl与Kubernetes API Server交互，它们之间的接口是RESTful API。API Server架构从上到下可以分为以下几层。（1）API层：主要以REST方式提供各种API接口，除了有Kubernetes资源对象的CRUD和Watch等主要API，还有健康检查、UI、日志、性能指标等运维监控相关的API。