Overview 阅读完本文，您当了解 Linux oom kill Kubernetes oom 算法 Kubernetes QoS 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大 什么是OOM Kill 当你的Linux机器内存不足时，内核会调用Out of Memory (OOM) killer来释放一些内存。这经常在运行许多内存密集型进程的服务器上遇到。 OOM Killer是如何选择要杀死的进程的？ Linux内核为每个运行的进程分配一个分数，称为 oom_score，==显示在内存紧张时终止该进程的可能性有多大==。该 Score 与进程使用的内存量成比例。 Score 是进程使用内存的百分比乘以10。因此，最大分数是 $100% \times 10 = 1000$。此外，如果一个进程以特权用户身份运行，那么与普通用户进程相比，它的 oom_score 会稍低。 在主发行版内核会将 /proc/sys/vm/overcommit_memory 的默认值设置为零，这意味着进程可以请求比系统中当前可用的内存更多的内存。这是基于以下启发式完成的：分配的内存不会立即使用，并且进程在其生命周期内也不会使用它们分配的所有内存。如果没有过度使用，系统将无法充分利用其内存，从而浪费一些内存。过量使用内存允许系统以更有效的方式使用内存，但存在 OOM 情况的风险。占用内存的程序会耗尽系统内存，使整个系统陷入瘫痪。当内存太低时，这可能会导致这样的情况：即使是单个页面也无法分配给用户进程，从而允许管理员终止适当的任务，或者内核执行重要操作，例如释放内存。在这种情况下，OOM Killer 就会介入，并将该进程识别为牺牲品，以保证系统其余部分的利益。 用户和系统管理员经常询问控制 OOM Killer 行为的方法。为了方便控制，引入了 /proc/<pid>/oom_adj 来防止系统中的重要进程被杀死，并定义进程被杀死的顺序。 oom_adj 的可能值范围为 -17 到 +15。Score 越高，相关进程就越有可能被 OOM-killer Kill。如果 oom_adj 设置为 -17，则 OOM Killer 不会 Kill 该进程。 oom_score 分数为 1 ~ 1000，值越低，程序被杀死的机会就越小。 oom_score 0 表示该进程未使用任何可用内存。 oom_score 1000 表示该进程正在使用 100% 的可用内存，大于1000，也取1000。 谁是糟糕的进程？ 在内存不足的情况下选择要被终止的进程是基于其 oom_score 。糟糕进程 Score 被记录在 /proc/<pid>/oom_score 文件中。该值是基于系统损失的最小工作量、回收的大量内存、不终止任何消耗大量内存的无辜进程以及终止的进程数量最小化（如果可能限制在一个）等因素来确定的。糟糕程度得分是使用进程的原始内存大小、其 CPU 时间（utime + stime）、运行时间（uptime - 启动时间）以及其 oom_adj 值计算的。进程使用的内存越多，得分越高。进程在系统中存在的时间越长，得分越小。...

本文使用 helm 方式部署 grafana 9 并同样将 keycloak 部署在 kubernetes 集群之上；接下来使用 keycloak 作为 grafana authentication，并实现 oauth2 的用户权限管理。 在Kubernetes 集群之上使用helm部署keycloak 在 kubernetes 集群安装 keycloak 有两种方式： bitnami helm offical 下面使用 offical 提供的方式进行部署 bash 1 kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes/keycloak.yaml helm 部署完成后默认密码是存储在 secret 中，上面方式安装的密码默认为 admin/admin Keycloak configuration 创建realm Realm 管理这一组用户(users), 凭据(credentials), 角色(roles) 和 组(groups)，realm之间是相互隔离，一个用户属于并登录到某个 realm，只能管理和验证其控制的用户。 下面为 grafana 创建一个 realm，如果你的环境已经存在通用的 realm，则可以使用这个 realm，默认 keycloak 的 realm 是 master，超级管理员属于这个 realm。 创建 client Client 是可以请求Keycloak对用户进行身份验证的实体。最常见用途是希望使用Keycloak来保护自己并提供单点登录(SSO)解决方案的应用程序和服务。客户端也可以是只希望请求身份信息或访问令牌的实体，以便它们可以安全地调用由 Keycloak 保护的网络上的其他服务。因此，我们需要为 grafana 创建一个 client...

背景与架构设计 网络中存在的挑战 挑战1：Kubernetes 的每个 Pod 拥有一个独立的 IP 地址。对外部访问则依赖 NodePort、LoadBalancer 或 Ingress，出于安全考虑不可能对每个 Pod 都暴露其 8849 端口 (NodePort) 或者使用 Ingress 配置大量的域名，这样无法连接到单独的某一个 Pod (通过Service)。 挑战2：网络环境是完全隔离的，用户无法通过 Pod IP 直接访问 Pod，所有的用户流量只能通过对应 IDC 的唯一入口进入。 挑战3：出于安全考虑不可能对每一个 Java 服务 (Pod) 在他的工作周期期间所有时间都暴露对应的 Jprofiler 端口，而仅仅想使用时可以连接，用后关闭。 JProfiler网络需求 JProfiler 可以通过加载 JVM 代理（libjprofilerti.so）与远程 GUI 通信，他的实现原理如下： JVM 启动时加载 JProfiler 代理，绑定到一个特定端口（如 8849）。 本地 JProfiler GUI 通过该端口连接到远程 JVM。 代理与 GUI 之间通过 TCP 传输性能数据。 在 Kubernetes 中，JProfiler 代理运行在 Pod 内部，但由于网络隔离和动态 IP，GUI 无法直接连接到 Pod。因此，我们需要一种机制将 JProfiler 的端口动态映射到可访问的外部端点。 需要实现的架构 下图是基于上面提到的问题从而设计的集群架构...

什么是传感器 传感器 (Sensor) 是将外部系统和事件与 StackStorm 集成的一种方式。传感器是 Python 代码片段，它们要么定期轮询某些外部系统，要么被动等待入站事件，通常示例用于每隔一段时间去轮询某一个对象，然后他们将 Trigger 注入 StackStorm，可以通过规则进行匹配，以执行潜在的 Action。 Sensor 是用 Python 编写的，并且必须遵循 StackStorm 定义的传感器接口要求。 什么是触发器 触发器 (Trigger) 是 StackStorm 中用于识别 StackStorm 的传入事件。Trigger 是类型（字符串）和可选参数（对象）的元组。编写 Rule 是为了与 Trigger 一起使用。Sensor 通常会记录 Trigger，但这并不是严格要求的。例如，有一个向 StackStorm 注册的通用Webhooks触发器，它不需要自定义传感器。 Stackstorm内置触发器 默认情况下，StackStorm 会发出一些内部 Trigger，您可以在规则中利用它们。这些触发器可以与非系统触发器区分开来，因为它们的前缀为 “st2”。 下面包含每个资源的可用 Trigger 列表： Action Reference Description Properties core.st2.generic.actiontrigger 封装 Action 执行完成的触发器 execution_id, status, start_timestamp, action_name, action_ref, runner_ref, parameters, result core.st2.generic.notifytrigger 通知触发器 execution_id, status, start_timestamp, end_timestamp, action_ref, runner_ref, channel, route, message, data core....

什么是包 包 “pack” 是扩展 StackStorm 的集成和自动化的部署单元。通常， pack 是沿着服务或产品边界组织的，例如 AWS、Docker、Sensu 等。 pack 包含Actions、Workflows、Rules、 Sensors和Aliases。StackStorm 内容始终是 pack 的一部分，因此了解如何创建 pack 并使用它们非常重要。 一些 pack 扩展了 StackStorm 以将其与外部系统集成，例如 AWS，GitHub，JIRA。我们称它们为“集成 pack ”。有些 pack 捕获自动化模式：这类 pack 含特定自动化过程的 workflow, Rule 和 Action - 例如st2 演示 pack 。我们称它们为“自动化 pack ”。这种命名主要是一种约定：StackStorm 本身对两者没有区别。 任何使用该 pack 所针对的服务的人都可以共享和重用集成 pack 。您可以在StackStorm Exchange找到许多这样的示例。自动化 pack 通常是特定于站点的，并且在特定团队或公司之外几乎没有用处；它们通常在内部共享。 总结：Packs是StackStorm中组织工作流、动作和传感器的方式。它们是一组相关的动作、工作流和传感器的集合，通常用于实现特定的自动化任务或集成。 包管理 StackStorm pack 通过命令进行管理：将为您提供有用的概述。st2 pack <...> / st2 pack -h 有些（例如core 基本 StackStorm action）是随 StackStorm 预装的。所有其他 pack 都需要您安装。幸运的是，这很容易！ list和get是获取有关本地 pack 信息的主要命令：...

StackStorm 使用 Rules 和 Workflows 来捕获操作模式并进行自动化。rule将 Triggers 映射到 Actions（或 Workflow），应用匹配条件( Criteria)，并将 Triggers payloads 映射到 Actions 的 Input。 注意 rule不按预期工作吗？请查看rule故障排除文档。其中介绍了rule测试、检查执行、记录和故障排除等内容。 Rule 的配置结构 stackstorm 中的 Rule 是以 YAML 格式来定义。以下是 Rule 定义结构以及 “必需”和 “可选” rule 元素的列表： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --- name: "rule_name" # required pack: "examples" # optional description: "Rule description." # optional enabled: true # required trigger: # required type: "trigger_type_ref" criteria: # optional trigger....

在我们基于 Kubernetes 编写云原生 GoLang 代码时，通常在本地调试时，使用 kubeconfig 文件，以构建基于 clientSet 的客户端。而在将代码作为容器部署到集群时，则会使用集群 (in-cluster) 内的配置。 clientcmd 模块用于通过传递本地 kubeconfig 文件构建 clientSet。因此，在容器内使用相同模块构建 clientSet 将需要维护容器进程可访问的 kubeconfig 文件，并设置具有访问 Kubernetes 资源权限的 serviceaccount token。 下面是一个基于 kubeconfig 访问集群的代码模式 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 var ( k8sconfig *string //使用kubeconfig配置文件进行集群权限认证 restConfig *rest.Config err error ) if home := homedir.HomeDir(); home != "" { k8sconfig = flag.String("kubeconfig", fmt.Sprintf("./admin.conf"), "kubernetes auth config") } flag....

本文记录了在 kubernetes 环境中，使用 cephfs 时当启用了 fscache 时，由于网络问题，或者 ceph 集群问题导致的整个 k8s 集群规模的挂载故障问题。 结合fscache的kubernetes中使用cephfs造成的集群规模故障 在了解了上面的基础知识后，就可以引入故障了，下面是故障产生环境的配置 故障发生环境 软件 版本 Centos 7.9 Ceph nautilus (14.20) Kernel 4.18.16 故障现象 在 k8s 集群中挂在 cephfs 的场景下，新启动的 Pod 报错无法启动，报错信息如下 bash 1 ContainerCannotRun: error while creating mount source path /var/lib/kubelet/pods/5446c441-9162-45e8-0e93-b59be74d13b/volumes/kubernetesio-cephfs/{dir name} mkcir /var/lib/kubelet/pods/5446c441-9162-45e8-de93-b59bte74d13b/volumes/kubernetes.io~cephfs/ip-ib file existe 主要表现的现象大概为如下三个特征 对于该节点故障之前运行的 Pod 是正常运行，但是无法写入和读取数据 无法写入数据 permission denied 无法读取数据 kublet 的日志报错截图如下 彻底解决方法 需要驱逐该节点上所有挂在 cephfs 的 Pod，之后新调度来的 Pod 就可以正常启动了 故障的分析 当网络出现问题时，如果使用了 cephfs 的 Pod 就会出现大量故障，具体故障表现方式有下面几种 新部署的 Pod 处于 Waiting 状态...

在安装和注册集群完成后，就需要引入第一个概念 “Application”（如何管理所有我的应用程序？） 什么是 Application 什么是 ArgoCD “Application”？ 对于 ArgoCD “Application”的快速解释：它是托管 ArgoCD 部署的 Kubernetes 集群 CRD 包含了应用程序的所有设置，如： 要部署到哪个集群？ 与哪个 Git 存储库进行同步？ 其他部署设置 应用程序的 YAML 包含了部署您的存储库资源所需的所有信息，充当了在 ArgoCD 中管理应用程序的关键控制点。 Reference ​[1] docs/operator-manual/argocd-cm.yaml ​[2] Getting started with multi-cluster K8S deployments using Argo CD ​[3] https://medium.com/notive/managing-argocd-application-resources-1b2b4742ab90

登录argo cd bash 1 argocd login argocd_server:argocd_port_here 执行后输入admin/sercert bash 1 2 3 4 5 6 $ argocd login 10.0.0.5:30908 WARNING: server certificate had error: x509: cannot validate certificate for 10.0.0.5 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y Username: admin Password: 'admin:login' logged in successfully Context '10.0.0.5:30908' updated argocd cli 登录后的文件保存在 ~/.argocd/config 中 注册一个新集群 argocd 通过 kubectl 来获取集群的信息，所以 argocd 的主机上必须有 kubeconfig 文件 Note: KUBECONFIG 文件地址必须为实际路径，比如 ~/ 这种方式不可以...

引言 在 NGINX 中常用一种 “比较变量” 的手法，在编程语言中称为 “多路分支” (Case statement)，也就是 nginx map，需要注意的一点是，太低版本 NGINX MAP 中只能使用单变量 Before version 0.9.0 only a single variable could be specified in the first parameter. [1] 下面将了解下 nginx map 的具体使用方式 nginx map使用 Nginx 配置主要是声明性的，这同样应用于 MAP 指令，NGINX MAP 是定义在 http{} 级别，最大的特点是仅在引用时进行处理， 如果请求未触及使用 NGINX MAP 变量的配置部分，则不会执行该 map 变量查找。换句话来理解，当在上下文 server, Location, if 等中使用结果变量时（指定的不是计算结果，而是在需要时计算该结果的公式），才会被使用，在 NGINX 需要使用该变量之前，NGINX MAP 不会给请求增加任何开销。 NGINX MAP 用于根据另一个变量的值创建一个变量，如下所示： text 1 2 3 4 map $variable_to_check $variable_to_set { "check_if_variable_matches_me" "variable_matches_checked_value"; default "no_match"; } 在上面的例子中， 变量 $variable_to_set 的被设置的结果为：如果 $variable_to_check 值为 “check_if_variable_matches_me”， 那么 $variable_to_set 将被设置为值 “variable_matches_checked_value” ， 否则将设置为 “no_match”。...

GKE标准机器通常费用组成为 “集群管理费” + 标准GCE主机费用，以香港为例 主机规格 CPU (CORE/Mon) MEM (GB/Mon) E2( E2Balanced: N1, N2)：费用优化 $23.77 $2.99 N1 (旧型号的Intel Sandy Bridge、Ivy Bridge、Haswell、Broadwell、Skylake) $38.45 $4.55 N2 CPU $31.9 $4.01 N2D CPU $27.75 $3.48 选择核心的标准（强要求） intel 2的公差，例如1, 2, 4, 6, 8, 10 AMD 2, 4, 8, 16, 32 只有 “费用优化” (cose-optimized) 的可以自定义配置，计算优化，内存优化等都是固定配置 新加坡的价格是香港价格的 “90%”

相关阅读：深入理解Kubernetes 4A - Admission Control源码解析 准入 (Admission) 是 Kubernetes 提供 4A 安全认证中的一个步骤，在以前版本中 (1,26-)，官方提供了 webhook 功能，使用户可以自行的定义 Kubernetes 资源准入规则，但这些是有成本的，需要自行开发 webhook，下图是 Kubernetes准入控制流程。 图：Kubernetes API 请求的请求处理步骤图 Source：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ 在 Kubernetes 1.26 时 引入了 ValidatingAdmissionPolicy alpha 版，这个功能等于将 Admission Webhook controller 作为了一个官方扩展版，通过资源进行自行扩展，通过这种方式带来下面优势： 减少了准入请求延迟，提高可靠性和可用性 能够在不影响可用性的情况下失败关闭 避免 webhooks 的操作负担 ValidatingAdmissionPolicy 说明 验证准入策略提供一种声明式的、进程内的替代方案来验证准入 Webhook。 验证准入策略使用通用表达语言 (Common Expression Language，CEL) 来声明策略的验证规则。 验证准入策略是高度可配置的，使配置策略的作者能够根据集群管理员的需要， 定义可以参数化并限定到资源的策略 下面是一个 ValidatingAdmissionPolicy 的示例，配置 Deployment 必须拥有的副本数的限制 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: admissionregistration....

“IP 伪装” 通常应用于云环境中，例如 GKE, AWS, CCE 等云厂商都有使用 “IP伪装” 技术，本文将围绕 “IP伪装” 技术本身，以及这项技术在 Kubernetes 集群中的实现应用 ip-masq-agent 的源码分析，以及 ”IP伪装“ 能为 Kubernetes 带来什么作用，这三个方向阐述。 什么是IP伪装？ IP 伪装 (IP Masquerade) 是 Linux 中的一个网络功能，一对多 (1 to Many) 的网络地址转换 (NAT) 的功能 。 IP 伪装允许一组计算机通过 “伪装” 网关无形地访问互联网。对于互联网上的其他计算机，出站流量将看起来来自于 IP MASQ 服务器本身。互联网上任何希望发回数据包（作为答复）的主机必须将该数据包发送到网关 （IP MASQ 服务器本身）。记住，网关（IP MASQ 服务器本身）是互联网上唯一可见的主机。网关重写目标地址，用被伪装的机器的 IP 地址替换自己的地址，并将该数据包转发到本地网络进行传递。 除了增加的功能之外，IP Masquerade 为创建一个高度安全的网络环境提供了基础。通过良好构建的防火墙，突破经过良好配置的伪装系统和内部局域网的安全性应该会相当困难。 IP Masquerade 从 Linux 1.3.x 开始支持，目前基本所有 Linux 发行版都带有 IP 伪装的功能 什么情况下不需要IP伪装 已经连接到互联网的独立主机 为其他主机分配了多个公共地址 IP伪装在Kubernetes集群中的应用 IP 伪装通常应用在大规模 Kubernetes 集群中，主要用于解决 “地址冲突” 的问题，例如在 GCP 中，通常是一种 IP 可路由的网络模型，例如分配给 Pod service 的 ClusterIP 只能在 Kubernetes 集群内部可用，而分配 IP CIDR 又是一种不可控的情况，假设，我们为 k8s 分配的 IP CIDR 段如下表所示：...

在Prometheus node-exporter中，存在多个网络监控指标指标标志着主机的网络状态，但是大家常常忽略这些指标，而这些指标又很重要，这些指标的来源是根据Linux网络子系统中的多个计数器定义的，本文就解开这些TCP计数器的面目。 TcpExtListenOverflows 和 TcpExtListenDrops 当内核从客户端接收到 SYN 时，如果 TCP 接受队列已满，内核将丢弃 SYN 并将 TcpExtListenOverflows +1。同时内核也会给TcpExtListenDrops +1。当 TCP 套接字处于 LISTEN 状态，并且内核需要丢弃数据包时，内核总是将 TcpExtListenDrops +1。因此，增加 TcpExtListenOverflows 将使 TcpExtListenDrops 同时增加，但在不增加 TcpExtListenOverflows 的情况下，TcpExtListenDrops 也会增加，例如内存分配失败也会导致 TcpExtListenDrops 增加。 以上解释基于内核 4.10 或更高版本，在旧内核上，当 TCP 接受队列已满时，TCP Stack有不同的行为。在旧内核上，TCP Stack不会丢弃 SYN，它会完成 3 次握手。当接受队列已满时，TCP 堆栈会将套接字保留在 TCP 半开队列中。由于处于半开队列中，TCP 堆栈将在指数退避计时器上发送 SYN+ACK，在客户端回复 ACK 后，TCP Stack检查接受队列是否仍满，如果未满，则将套接字移至接受队列如果队列已满，则将套接字保留在半开队列中，下次客户端回复ACK时，该套接字将有另一次机会移至接受队列。 这两个计数器在 node_expoter 中的指标是： node_netstat_TcpExt_ListenDrops node_netstat_TcpExt_ListenOverflows TcpInSegs 和 TcpOutSegs TcpInSegs 和 TcpOutSegs 都是被定义在 RFC1213 [1] TcpInSegs 是指 TCP layer 接收到的数据包数量，包括错误接收的数据包，例如校验和错误、无效的TCP头等。只有一个错误不会被包含在内：如果第 2 层目标地址不是 NIC 的第 2 层地址。如果数据包是多播或广播数据包，或者 NIC 处于混杂模式，则可能会发生这种情况。在这些情况下，数据包将被传递到 TCP 层，但 TCP 层将在增加 TcpInSegs 之前丢弃这些数据包。 TcpInSegs 计数器不知道 GRO (Generic Receive Offload)。因此，如果两个数据包被 GRO 合并，TcpInSegs 计数器只会增加 1。...

GitOps 最初由 Weaveworks (weave cni的组织) 在 2017 年的博客中提出 [1]，使用 “Git” 作为 CI/CD 的 “单一事实来源”，将代码的更改集成到每个项目的存储库中，并使用拉取请求来管理 infra 和部署。 在理解上就可以理解为 “是一种基于 git 的操作框架” Argo CD 是一种 kubernetes 之上的 “声明式” (declarative) 的 gitops CD， 在本文作为了解如何在 Kubernetes 集群中安装和配置 Argo CD。 前提准备 想要安装 Argo CD 首先环境需要具备如下： 已经安装好 kubectl 命令行工具 拥有 kubeconfig 文件 一个可供测试的 Kubernetes 集群，如：kind, minikube, kubeadm, binary 等任意的集群 步骤1 - 选择适配 kubernetes 版本的 Argo 根据官方的解释， Argo CD 在任何给定时刻所支持的版本，这些版本是 N 和 N - 1 次要版本的最新修补版本 (x.x.new)。这些 Argo CD 版本与 Kubernetes 项目官方支持的 Kubernetes 版本相一致，通常是 Kubernetes 的最近发布的 3 个版本。...

Argo组件 API Server Repository Server Application Controller API Server：一个 gRPC/REST 服务器，提供了 “Web UI”、“CLI” 和 “CI/CD” 使用的 API 应用管理和状态报告 调用应用操作（例如同步、回滚、用户定义的操作） 存储库和 Cluster credential 管理（作为 kubernetes secret 存储） 为外部提供身份认证和代理授权功能 RBAC 试试 Git webhook 事件的 listener/forwarder Repository Server：内部服务，用于维护 git 中的应用清单 (manifests) 的本地缓存。负责接收生成和返回 kubernetes 清单 仓库URL revision (commit, tag, branch) APP PATH 模板特定的参数 Application Controller：Kubernetes controller，主要做的工作是持续监控运行的 Application，并于当前实时状态和目标所需状态进行对比（与 Kubernetes Controller 功能是相同的），并且不仅仅是 KC 还会和存储库中指定目标状态进行比较，检测到 OutOfSync 状态将进行纠正。 Argo 架构 Argo CD 时最常见的三种架构：单实例方案, 集群级方案，以及折衷方案 (compromise between the two)。...

10月11日发布的 curl 8.4.0版本，在新版本中修复漏洞 CVE-2023-38545 和 CVE-2023-38546 CVE-2023-38545: This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. [1] CVE-2023-38546: This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. [2] 安装方式有两种，“编译” 与 “更新RPM”，本文以 RPM 方式更新 curl 到 8.4.0 版本 下载curl源码包 升级至少需要更新至 curl 8.4 ，首先从官网下载源码包 [3] 将curl打包为rpm 因为 curl 源码包内没有提供 rpm 的规格文件，所以我们需要自己编写，但是比较麻烦，可以让 chatgpt 生成一个，这里使用 centos7 的 curl....

在本文，尝试使用 Docker 运行 PostgreSQL ，为了适配 goalert 项目，因为从来没有尝试过使用 PostgreSQL 了解PostgreSQL数据库 在我们继续运行 PostgreSQL 数据库的 Docker 容器之前，我们先来了解一下 PostgreSQL 数据库。 PostgreSQL 是一个开源 RDMS，类似于 MySQL。它是一个面向对象的数据库，但我们可以处理结构化和非结构化数据。 PostgreSQL 数据库可以运行在各种平台上，包括 Windows、Mac OS X 和 Linux。它还提供高级数据类型和性能优化功能来存储和扩展复杂的数据库工作负载。 一些常见的 postgres 镜像 镜像 说明 postgres:latest 最新的一个稳定版本 postgres:17 PostgreSQL version 14.x （x为最近的一次 patch） postgres:17.4 17.4 一个具体的版本 postgres:bookworm 使用 Debian Bookworm (12) 构建的 PostgreSQL postgres:15-bookworm 使用 Debian Bookworm (12) 构建的 PostgreSQL 15 使用公共镜像运行PostgreSQL 要使用 Docker 运行 PostgreSQL，我们首先需要拉取 Docker Hub 上可用的 postgres 公共镜像： bash 1 docker pull postgres 在上面的命令中，我们拉取了 postgres 最新的稳定版镜像。 如果要指定版本的 postgres 镜像，可以使用以下命令...

工具命令集合 长期总结 - Linux日志查询命令 长期总结 - Linux网络命令合集 长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例 探索kubectl - 巧用jsonpath提取有用数据 探索kubectl - kubectl诊断命令集合 kubernetes集群工具 kubect 提供了一种强大的数据提取的模式，jsonpath，相对于 yaml 来说，jsonpath 拥有高度的自制提取功能，以及一些更便于提取字段的模式，使得过去 kubernetes 资源信息时更便捷，在本文中将解开 jsonpath 的神秘面纱。 什么是jsonpath JSONPath 是一种用于查询 JSON 数据结构中特定元素的查询语言。它类似于 XPath 用于 XML 数据的查询。JSONPath 允许您以一种简单而灵活的方式从 JSON 对象中提取数据，而不需要编写复杂的代码来解析 JSON 结构。 JSONPath 使用路径表达式来指定您要检索的 JSON 数据的位置。这些路径表达式类似于文件系统中的路径，但用于导航 JSON 结构。以下是一些常见的 JSONPath 表达式示例： $：表示 JSON 根对象。 $.store：表示从根对象中获取名为 “store” 的属性。 $.store.book：表示从根对象中获取 “store” 属性中的 “book” 属性。 $.store.book[0]：表示获取 “store” 属性中的 “book” 属性的第一个元素。 $.store.book[?(@.price < 10)]：表示选择 “store” 属性中的 “book” 属性中价格小于 10 的所有元素。 Function Description Example Result text the plain text kind is {....