u010674101的专栏

通过上述方法可以排查出节点故障原因，比如资源耗尽、服务故障、网络中断等。根据具体问题采取相应的措施，如重启服务、增加资源、调整网络配置等，从而恢复节点正常状态。

在 Kubernetes 中，可以使用命令查看 Pod 的资源使用情况，从而找到 CPU 使用率最高的 Pod。

Sidecar 代理是一种灵活而强大的设计模式，广泛用于微服务和 Kubernetes 集群中，用来提升网络管理、监控、日志记录和安全性的能力。虽然它增加了一定的复杂性和资源消耗，但为应用隔离职责、提升可观测性和提高可靠性提供了有力的支持。sidecar.py扮演了 Sidecar 代理的角色，负责拦截并记录流量。app.py是主服务，处理实际的业务逻辑。kubectl和ConfigMap用于管理和部署 Pod，使主服务和代理服务共存于一个 Pod 中。

适合快速查看单个或少量 Pod 日志。EFK和：适合集中式日志管理、存储和可视化，便于长时间监控和分析日志数据。

在 Kubernetes 中，（PV）和（PVC）用于管理存储资源。PV 是集群中的存储资源，而 PVC 是 Pod 请求 PV 的方式。按需创建 PV 通常使用 StorageClass 实现动态存储分配，PVC 通过声明请求所需的存储量与访问模式来绑定相应的 PV。以下是按需创建 PV 和使用 PVC 的具体步骤。

在 Kubernetes 中，可以通过以下步骤将 Pod 调度到指定节点、创建多容器 Pod，并查找 Pod 日志。

deployment扩容-查看pod使用的CPU-统计ready状态节点数量

Kubernetes 的 Ingress 用于七层（L7）负载均衡，它在应用层（主要是 HTTP/HTTPS 协议）上为集群中的服务提供外部访问，并允许基于请求的内容（如路径、域名）将流量转发到不同的服务。这在实现复杂的路由规则时非常有用，比如根据 URL 路径或主机名将流量导向不同的后端服务。

在 Kubernetes 中，通过 Service 可以实现四层（L4）负载均衡，将流量分发至后端的 Pod。四层负载主要用于传输层（TCP/UDP），而不像七层负载均衡（HTTP/HTTPS）那样进行应用层的流量处理。

提供了一种方式来控制 Kubernetes 集群中 Pod 之间的网络流量，类似于防火墙规则。通过选择合适的ingress和egress规则，可以实现精细的流量控制。需要网络插件的支持才能生效，并且默认行为是一旦有 NetworkPolicy，则会阻止未允许的流量。

提供了一种方式来控制 Kubernetes 集群中 Pod 之间的网络流量，类似于防火墙规则。通过选择合适的ingress和egress规则，可以实现精细的流量控制。需要网络插件的支持才能生效，并且默认行为是一旦有 NetworkPolicy，则会阻止未允许的流量。

在 Kubernetes 集群中，etcd是一个分布式键值存储，它保存着整个集群的状态，包括节点、Pod、ConfigMap、Secrets 等关键信息。因此，定期对etcd进行备份是非常重要的，特别是在集群发生故障或需要恢复数据的情况下。本文将介绍如何备份和恢复 Kubernetes 中的etcd数据。

Kubernetes 集群版本升级是为了获得最新的功能、增强的安全性和性能改进。然而，升级过程需要谨慎进行，特别是在生产环境中。通常，Kubernetes 集群的版本升级应遵循逐步升级的策略，不建议直接跳过多个版本。

Kubernetes (K8s) 中对 Node 节点的维护是保证集群健康和性能的重要部分。Node 节点通常是 Kubernetes 工作负载的运行环境，负责运行 Pods。当需要对节点进行维护（如升级、修复问题、调整配置等）时，可能需要将该节点标记为不可用并迁移其上的工作负载。

kubeconfig文件是 Kubernetes 的配置文件，kubectl使用它来连接和与 Kubernetes 集群交互。它通常位于路径下，包含多个上下文、集群、用户的配置信息，用于定义kubectl如何与不同的集群进行通信。kubeconfig。

kubectl的命令用于在 Kubernetes 集群中切换上下文（context），从而方便地在多个集群或命名空间之间进行操作。一个上下文定义了kubectl使用的和的组合。

在 Kubernetes 中，和是两个 API 组的版本化接口，它们用于处理不同类型的资源和操作。

最近一直在升级过期的ack 集群版本 从1.22升级到1.24.。

Kubelet的垃圾回收功能可以清理不再使用的容器和镜像，kubelet对容器进行垃圾回收的频率是每分钟一次，对镜像进行垃圾回收的频率是每五分钟一次。不推荐使用外部的垃圾回收工具，因为这些工具有可能会删除 kubelet 仍然需要的容器或者镜像。

原来是nginx访问java的/actuator接口就会返回200的情况，通过ip+端口的情况才可以访问到java服务的健康信息。由于同时把原来的服务通过nginx转发的，迁移到K8S后，ingress没有做细化的规则配置。在ingress路由正常使用的情况下，添加server-snippet 注解即可。输入ingress路由进行访问，测试验证结果，同时测试其他接口有没有问题。反正这个nginx-ingress 是阿里云默认的那个。使用了alb转发的。

只要apiserver容器重启了加载了新证书即可，否则请查询apiserver日志。更新/etc/kubernetes/pki目录下的所有证书（不包含ca证书）由于我之前是有kubekey部署的，在我的电脑上找了很久配置文件才找到。可以看到这个文章，我部署的，1年到期，童嫂无欺！话说回来，证书过期，真是一个巨坑。注意：需要在每一个节点上都更新。

云原生gitlab在k8s上配置ingress ssh端口访问仓库

这个是ack官方的图，由于他文章有部分，有时候说得我头晕眼花了，于是抽出来记录一下。

由于需要迁移数据到新的服务，但是服务在不同命名空间，而且ack nas存储不支持快照。于是想到使用rsync pod 2 pod办法。源pod （业务pod并自行安装了rsync） -> 目标迁移pod（open-ssh-server）根据实际情况挂载具体的pvc，这个yaml删除了挂载pvc部分。比如挂载在/data目录。在业务pod有rsync的另一端进行操作。同步目录到目标容器。

今天在k8s上部署gitlab，由于是helm chart方式部署，StorageClass示例文件上没有说明如何更改StorageClass类型，只是说明了，如果不填写StorageClass 类型，将会是默认的存储类型。

查看ack绑定了哪个nas实例id

版本kk versionversion.BuildInfo{Version:"1.1.1", GitCommit:"7f4b70f", GitTreeState:"", GoVersion:"go1.14.15"}# kubernetes:# version: v1.20.4停止调度工作节点由于我的node3节点，周末停电坏掉了，需要剔除K8S工作节点。删除节点我使用了kubekey删除失败，无奈之下，使用原生命令执行删除。$ kubectl top nodeNAME

这个玩意在K8S上部署，和docker上部署其实是差不多的。就是需要转换一下。创建数据库并导入数据在他的官网仓库找到这个脚本 tables_xxl_job.sql## XXL-JOB v2.3.1-SNAPSHOT# Copyright (c) 2015-present, xuxueli.CREATE database if NOT EXISTS `xxl_job` default character set utf8mb4 collate utf8mb4_unicode_ci;use `x

kubectl apply -f job.yaml，执行yaml文件进行基准测试，然后会生成报告。#job.yaml---apiVersion: batch/v1kind: Jobmetadata: name: kube-benchspec: template: metadata: labels: app: kube-bench spec: hostPID: true containers: - name

先决条件Kubeapps 假设有一个可用的 Kubernetes 集群 (v1.15+)，以及helm(3.1.0+) 和kubectl命令行接口已安装并配置为与您的 Kubernetes 集群通信。Kubeapps 已经过 Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)minikube和 Docker for Desktop Kubernetes 的测试。Kubeapps 在启用了 RBAC 的集群上工作，为了更安全的安装，鼓励

helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ --set nfs.server=192.168.5.226 \ --set nfs.path=/mnt/demo \ --set image.tag=v4.0.2 \ --set image.repository=xxxxxxx/nfs-subdir-ex

在已经搭建好的集群里，${HOME}/.kube/config 下会有这个config文件。直接把他弄到你的远程控制端电脑或者pc或者笔记本。#rsync -av root@k8s-node02:/root/.kube ./#然后执行如下命令，有返回正确的信息。#kubectl cluster-info Kubernetes control plane is running at https://lb.kubesphere.local:6443coredns is running at htt

安装 bash-completionapt-get install bash-completion或yum install bash-completion启用 kubectl 自动补全echo 'source <(kubectl completion bash)' >>~/.bashrckubectl completion bash >/etc/bash_completion.d/kubectl#如果上一句执行错误的话，就执行下面一句#kubectl completio

上次部署了一主两从，现在扩展多一个工作节点为一主三从节点。本次增加了node3节点，并尝试使用密钥模式进行部署，有密码密钥尝试过，但是已经失败。apiVersion: kubekey.kubesphere.io/v1alpha1kind: Clustermetadata: name: samplespec: hosts: - {name: master, address: 192.168.5.11, internalAddress: 192.168.5.11, user: root,

今天重启了一下，服务器，结果发现昨天部署的k8s环境无法正常使用了。。看来单机版本还是适合开发环境。重启服务器后没有可以到达k8s服务的路由了，iptables规则已经被清空。[root@k8s-test ~]# kubectl get pvc --all-namespaces Unable to connect to the server: dial tcp: lookup lb.kubesphere.local on 202.96.128.86:53: no such host[root@k8s-

部署过程本文kubesphere 和k8s一起部署，系统centos7.9[root@k8s-test ~]# curl -sfL https://get-kk.kubesphere.io | VERSION=v1.1.1 sh -Downloading kubekey v1.1.1 from https://github.com/kubesphere/kubekey/releases/download/v1.1.1/kubekey-v1.1.1-linux-amd64.tar.gz ...