公司内所有服务基本容器化结束，全都是Java，所以内存显得也尤为重要，有部分服务的内存交给了开发优化，优化之后，发现容器监控层面的wss会持续增长。这里说下内存的wss和rss，其实之前我也不懂，涉及以下几个概念。 VSS：Virtual Set Size 虚拟耗用的内存(包含与其他进程共享占用的虚拟内存），说实话我查到的资料，这个统计的内存没用，所以没看。RSS：Resident Set...

对于 Java 等需要预热的语言与框架而言，在容器刚启动的时候，有可能会出现分钟级别的CPU、内存飙高，其可能会造成HPA的误触发。 上面这句原话出自阿里云ACK服务文档，确实也是我在生产中遇到的问题，cpu 给高了吧，有点浪费资源，给低了吧，每次发版启动时就会触发 HPA，也会一直告警，很烦，一开始我以为配置在 HPA 里面，把 HPA 的文档都泛滥了，甚至对于 HPA 的使用更深了，也没...

应公司开发要求业务分离需要用到 ETCD 数据库，因为资源问题，也就不申请机器在虚机部署了，准备直接上容器，开发/测试/预生产都上了单节点的 ETCD 对于 ETCD 的容器化部署，官方目前只有 docker 容器的部署方式 https://etcd.io/docs/v3.6/install/ https://github.com/etcd-io/etcd/releases ，有一个 bit...

之前在学习 storageclass 的时候使用过 nfs-client 的外部存储，原文地址：Kubernetes-StorageClass-动态供给 当时有个 bug，需要修改 apiserver 静态 pod 的配置，今天我使用 1.24.0 的 k8s 集群部署时，仍然有这个 bug，根据当时的方法已经无法解决了，所有找了另一个 nfs 外部存储的方法，项目地址：https://gi...

受疫情影响，公司收益也大受影响，从我入职以来一直在进行成本缩减，不要问，问就是我没被裁。现在已经轮到 k8s 节点倒霉了，要准备对几台节点进行裁员，由我来进行方案定制 Kubernetes生产节点缩容方案 worker节点数 14 单节点 16c64g 评估各节点 pod 数量和资源使用情况，根据综合比使用各项资源最少的进行缩减规划工作,尽量减少 pod 驱逐后最小化对业务的实际影响，...

在之前的文章 通过 Service 访问 Pod 集群 中，学习了两种方法做 pod 负载，分别是 ClusterIP 和 NodePort ，也提到了 LoadBalancer，仅仅是提了一嘴。

在正常的生产环境中，当使用了 NodePort 类型暴露服务时，每台集群节点的 nodeport 端口都能够去访问，

使用 kubectl 命令时，最烦人的就是频繁的切换命名空间了，查看什么资源都得加命名空间，每次敲命令在习惯也会很烦。今天在网上看到一篇文章，很有用，可以记住上一次使用 kubectl 时操作的命名空间。

在实际的生产环境中遇到了这样的问题：集群中有大量 k8s 节点，在部署应用时，需要拉取私有仓库（harbor/registry）的私有项目镜像，也就是节点必须 docker login 之后才可以正常拉取到镜像。但是也不可能每个节点都这样去做，或者写脚本把用户密码明文暴露，显然是不合适的

需要将镜像仓库的认证凭据（域名/ip，用户名，密码）保存在 k8s 中

Kubernetes 的版本更新迭代算是频繁的了，每个三个月发布一个小版本。为了使集群中一直跟随着版本前进，如果一直不更新，会导致新功能无法使用，落后新版本太多版本，不方便升级。

升级策略

• 始终保持最新
• 每半年升级一次，资源会落后社区1~2个小版本（推荐）
• 一年升级一次，或者更长，落后版本太多

Kubernetes 无论是二进制搭建还是 kubeadm 搭建的集群，都依赖于 etcd 数据库来进行存储集群数据，安全起见，一定要备份。一旦集群宕机，就会显得备份得多重要。

kubeadm etcd 备份恢复

kubeadm 部署的集群中的 etcd 是以静态容器的方式运行的，静态容器的配置文件存放目录是 /etc/kubernetes/manifests/，且默认 etcd 是单实例，并没有高可用。其实还是建议即使 kubeadm 部署时，也可以使用外部的 二进制部署的高可用 etcd 集群。

网络策略（Network Policy），用于限制 Pod 出入流量，提供 Pod 级别和 Namespace 级别网络访问控制。

已知 flannel 目前并不支持网络策略，即使创建了也并不会应用，其它组件在使用网络策略时还请自行了解以下是否支持。

应用场景

• 应用程序（Pod）间的访问控制。例如微服务 A ，允许访问微服务 B ，微服务 C 不能访问微服务 A
• 开发环境命名空间不能访问测试环境命名空间 Pod
• 当 Pod 暴露到外部时，需要做 Pod 白名单
• 多租户网络环境隔离（使用项目较多）

RBAC（Role-Based Access Control，基于角色的访问控制），允许通过 Kubernetes API 动态配置策略。 概念理解角色（权限的集合） Role：授权特定命名空间的访问权限 ClusterRole：授权所有命名空间的访问权限（集群角色） 角色绑定 RoleBinding：将角色（Role）绑定到主体（即subject） ClusterRoleBindin...

相信大家在使用 kubeadm init 时，会发现在 /etc/kubernetes/pki 目录下生成一大堆证书文件；还有一些 k8s 插件在部署时，会创建 RBAC，这些都是为了 kubernetes 的安全而产生的。

• K8S 安全控制框架主要有 3 个阶段进行控制，每一个阶段都支持插件方式，通过 API Server 配置来启用插件。

1. Authentication(鉴权)：鉴定访问集群的身份
2. Authorization(授权)：在确认身份的基础上，给定符合身份的权限
3. Admission Control(准入控制)：安检

在前面的学习中，发现做的例子都是 Deployment ，且大部分使用 web 应用去做示例，为什么不用 mysql 类似数据库来做示例呢。

在 LNMP 架构中，应该了解过动静分离，也就是动态数据和静态数据，是以是否需要去访问数据库去进行读写数据来区分的。

Kubernetes 同样也区分了有状态应用和无状态应用，之前常用的 Deployment 就是为无状态应用而使用的。本文中提到的 StatefulSet 就是为有状态应用使用的。

创建 nfs 的 storageClass 请跳到 Kubernetes–StorageClass(二)，因为 本文中的 NFS 仓库中的项目有点 bug ，对于新版 k8s 无法解决。不信邪你可以试试

在之前的文章 Kubernetes的数据管理 一文中，介绍了一些 volume 以及 PV 、 PVC 的使用方法，也被称为 静态 PV 供给，因为 PVC 是建立在 PV 的前提下，必须手动创建 PV ，再去创建 PVC 去匹配 PV 获取存储资源。

以上说到的方法中，对于大量 pod 的场景来说，维护成本相当大，对于运维人员也是不友好的。所以 k8s 支持了 PV 的动态供给 — StroageClass。也就是使用了 StorageClass 之后，不需要单独创建 PV，只需要创建 PVC ，就会根据 PVC 的申请自动创建一个 PV，也被称为 动态 PV 供给