x10n9的博客

nginx-ingress直接使用yaml来部署修改里面的镜像。

【代码】k8s组件监控指标梳理。

【代码】k8s v1.27.4 部署metrics-serverv:0.6.4。

k8s 二进制部署记录，版本v1.27.4

kubeadm 部署的k8s,网络插件使用的calico，发现其中一个calico-node pod在不断重启。从事件当中可以看出是解析localhost失败,导致Liveness probe failed,从而重启。最后在node节点的hosts文件中添加localhost并重启pod.查看node节点的hosts文件，确认没有localhost。

正确处理方式是,先确认POD容器的工作目录，然后把文件放到工作目录中，cp的时候不需要加’/'。kubectl cp 容器文件到本地。

遵循Unix/Linux顶级工具的传统，ktop是一个显示有关Kubernetes集群中运行的节点、pod和其他工作负载资源的有用度量信息的工具。安装了metrics Server时，ktop将显示由metrics Server报告的资源利用率度量。没安装metrics Server时，ktop将显示节点和pod的资源请求和限制，而不是资源利用率。无论安不安装metrics-server都可以使用。Kubernetes集群的类似top的工具。

可编程：DeepFlow 目前支持了对 HTTP、HTTPS、Dubbo、gRPC、ProtobufRPC、SOFARPC、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS协议的解析，并将保持迭代增加更多的应用协议支持。在云原生环境中，DeepFlow 的 AutoTagging 机制自动发现服务、实例、API的属性信息，自动为每个观测数据注入丰富的标签，从而消除数据孤岛，并释放数据的下钻能力。随着复杂度的增长，可观测性平台本身的可观测性能力同样也成为问题。

在部署k8s 跨集群通信submariner时，submariner-lighthouse-agent这个POD未能启动问题处理。

ingress-nginx controller-v0.47.0。

应用程序定义、配置和环境应该是声明式的，并受版本控制。应用程序部署和生命周期管理应该是自动化的、可审计的，并且易于理解。Argo CD是Kubernetes的一款声明式、GitOps连续交付工具。更改Argo SVC nodeport。为什么使用Argo CD。...

Rollout canary steps supports Metrics analysis, Hook Mechanism。

https://github.com/redhatxl/kubectl-img插件命名为：kubectl-img目前仅简单实现一个 image 命令，用于查看不同资源对象 (deployments/daemonsets/statefulsets/jobs/cronjobs) 的名称，和对应容器名称，镜像名称。支持 JSON 格式输出。最后将其作为 krew 插件使用。可以直接根据名称空间来进行查看对应资源。$ kubectl img image -hshow k8s resource imag

至少3个Kubernetes集群，其中一个被指定为中央代理，可供所有连接集群访问;不同的集群需要使用不同的CIDR使用手册：https://submariner.io/operations/usage/假设已有三个集群：集群1的kubeconfig /root/.kube/configip集群2的kubeconfig /root/.kube/configheader集群3的kubeconfig /root/.kube/config3集群1：安装subctlhttps://subma

日志格式：Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg如下：E1221 13:53:13.024436 4853 controller.go:152] Unable to remove old endpoints from kubernetes service: StorageError: key not found, Code: 1, Key: /registry/masterleases/172.30.1

k8s apiserver错误日志一真报以下错误，但是metricserver组件是正常的。loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: failed to retrieve openAPI spec, http error: ResponseCode: 503, Body: Error trying to reach service: 'read tcp 10.0.0.198:44512->10.0.0.198:443

通过k8s api 审批 kubelet 发起的 CSR 请求kubectl certificate approve node-csr-xxxxxxxxxxxxxxxxxxxxximport requests, jsonclass K8csr:def init(self, url, token):self._url = urlself._token = tokenself.headers = {“Authorization”: "Bearer " + self._token,“Accept”

1.工具简介Descheduler 的出现就是为了解决 Kubernetes 自身调度（一次性调度）不足的问题。它以定时任务方式运行，根据已实现的策略，重新去平衡 pod 在集群中的分布。2.github项目地址：https://github.com/kubernetes-sigs/descheduler3.兼容性列表下面的兼容性矩阵显示了k8s客户端包(client-go, apimachery等)的版本，用来编译去调度程序。 此时，去调度程序对特定的k8s版本没有硬依赖关系。 然而，特定的去调

背景：k8s集群，在已经部署了onlyoffice后，因某些原因升级节点的内核版本，5.15.x ,出现onlyoffice pod 频繁oom(配置了limits)的情况.问题（必现）：在任何一个升级了内核的节点运行onlyoffice(多个版本测试)容器，容器使用内存达到24G的情况，cpu200%+。直接使用docker run 启动进到容器内部：原因：未知解决：重新添加一个节点，先升级系统内核版本，再安装k8s,docker等组件，再运行onlyoffice后正常...

https://github.com/karmada-io/karmadaKarmada 是对 Kubefed 项目的延续，它继承了来自 kubefed 中的一些概念，目前也处于积极开发和维护中，这也是目前社区中比较活跃和成熟的集群联邦项目。架构图Karmada 本身与 Kubernetes 架构非常相似背景：已有两个k8s集群defaultremote安装：安装kubectl pluginwget https://gh-proxy.du33169.workers.dev/https:

**Deletion policy**All federated resources reconciled by the sync controller have a finalizer (kubefed.io/sync-controller) added to their metadata. This finalizer will prevent deletion of a federated resource until the sync controller has a chance to pe