Kubernetes Service 与 long-lived connections
本文将会介绍:
- 从 pod 到 service 再到 pod,kubernetes 中的流量是怎么走的?
- 对于 long-lived connection 长连接又是怎样的情况?
从 pod 到 service 再到 pod
如上图所示:
本文将会介绍:
如上图所示:
大家好,我是凌虚。
我于 2024 年 3 月 14 日参加了 Elastic Certified Engineer(ECE)认证考试,并与 18 日收到了考试通过的邮件。本文将会回顾我的考试过程、考试真题、个人感受。
如上图所示,本人于 2024 年 1 月 22 号晚上 11 点进行了 CKA 的认证考试,并以 95 分(满分100)顺利通过拿证。本文将会介绍我的 CKA 考试心得和速通攻略。
虽然 Redis 作为一个 key-value 数据库早已被广泛应用于各种缓存相关的场景,然而其团队的却并未故步自封,他们希望更进一步为开发者提供一个不只有缓存功能的强大的实时数据平台,用于处理所有实时数据的应用场景。
Kubernetes
集群外部的 HTTP/HTTPS 请求是如何达到 Pod 中的 container
的?
如上图所示,全过程大致为:
DNS
域名解析,得到对应的公网 IP
地址。IP
地址通常会绑定一个 Load Balancer
负载均衡器,此时请求会进入此负载均衡器。Load Balancer
负载均衡器可以是硬件,也可以是软件,它通常会保持稳定(固定的公网 IP 地址),因为如果切换 IP 地址会因为 DNS 缓存的原因导致服务某段时间内不可达。Load Balancer
负载均衡器是一个重要的中间层,对外承接公网流量,对内进行流量的管理和转发。Load Balancer
再将请求转发到 kubernetes
集群的某个流量入口点,通常是 ingress
。ingress
负责集群内部的路由转发,可以看成是集群内部的网关。ingress
只是配置,具体进行流量转发的是 ingress-controller
,后者有多种选择,比如 Nginx、HAProxy、Traefik、Kong 等等。ingress
根据用户自定义的路由规则进一步转发到 service
。service
根据 selector(匹配 label 标签)将请求转发到 pod
。service
有多种类型,集群内部最常用的类型就是 ClusterIP
。service
本质上也只是一种配置,这种配置最终会作用到 node 节点上的 kube-proxy
组件,后者会通过设置 iptables/ipvs
来完成实际的请求转发。service
可能会对应多个 pod
,但最终请求只会被随机转发到一个 pod
上。pod
最后将请求发送给其中的 container
容器。pod
内部可能有多个 container
,但是多个容器不能共用同一个端口,因此这里会根据具体的端口号将请求发给对应的 container
。以上就是一种典型的集群外部 HTTP 请求如何达到 Pod 中的 container
的全过程。
在分布式系统中,应用服务常常会通过多个节点(或实例)的方式来保证高可用。然而在某些场景下,有些数据或者任务无法被并行操作,此时就需要由一个特定的节点来执行这些特殊的任务(或者进行协调及决策),这个特定的节点也就是领导者(Leader),而在多个节点中选择领导者的机制也就是分布式选主(Leader Election)。
当用户向 Kubernetes
提交了一个创建 deployment
的请求后,Kubernetes
从接收请求直至创建对应的 pod
运行这整个过程中都发生了什么呢?
在搞清楚从 deployment
提交到 pod
运行整个过程之前,我们有先来看看 Kubernetes
的集群架构:
在 kubernetes 中有一系列内置的资源,诸如:pod
、deployment
、configmap
、service
…… 等等,它们由 k8s 的内部组件管理。而除了这些内置资源之外,k8s 还提供了另外一种方式让用户可以随意地自定义资源,这就是 CRD
(全称 CustomResourceDefinitions
) 。
原文为 Akihiro Suda 在日本京都大学做的在线讲座,完整的 PPT 可 点击此处下载
本文内容分为以下三个部分:
容器是一组用于隔离文件系统、CPU 资源、内存资源、系统权限等的各种轻量级方法。容器在很多意义上类似于虚拟机,但它们比虚拟机更高效,而安全性则往往低于虚拟机。
如何结合使用 JVM Heap 堆和 Kubernetes 内存的 requests 和 limits 并远离麻烦。
在容器环境中运行 Java 应用程序需要了解两者 —— JVM 内存机制和 Kubernetes 内存管理。这两个环境一起工作会产生一个稳定的应用程序,但是,错误配置最多可能导致基础设施超支,最坏情况下可能会导致应用程序不稳定或崩溃。我们将首先仔细研究 JVM 内存的工作原理,然后我们将转向 Kubernetes,最后,我们将把这两个概念放在一起。