借Kubernetes-Pod访问内部服务器组件
当我们在 Kubernetes 上工作时,有时会遇到这样的场景:我们需要从本地访问一个位于集群内部的 Redis 服务器,但出于安全考虑,这个 Redis 服务并没有直接暴露给外部。不过,集群里有一个 Pod 已经具备了访问这个 Redis 服务器的能力。 利用这个 Pod 作为跳板,我们可以安全地从本地连接到目标 Redis 服务器。由于这个 Pod 本身并不是 Redis 服务,我们不能直接使用 kubectl port-forward。相反,我们需要在 Pod 内部运行一个临时的代理进程。 下面是实现这个目标的详细步骤,可以作为你的操作笔记或博客文章。 借道 Kubernetes Pod 访问内部 Redis 服务器步骤零:先安装必要工具1apt install -y socat net-tools 步骤一:找到你的“跳板” Pod首先,你需要确定那个能够连接到 Redis 服务器的 Pod 的名称。你可以使用 kubectl 命令列出集群中的所有 Pod: 1kubectl get pods 从列表中找到你需要的 Pod,例如它的名字是 my-redis-client...
k9s的使用
简介在没有Web版的Dashboard的情况下,您可以使用命令行命令来管理您的Kubernetes集群。这使得您可以轻松地执行各种操作,例如查看资源、编辑资源、删除资源等。 资源监视:使用K9s,您可以轻松地监视和管理Kubernetes集群中的各种资源,例如Pod、Deployment、Service和ConfigMap等。资源修改:您可以使用K9s的资源编辑功能来修改这些资源,例如更新Pod的副本数量或更改Service的类型。K9s还提供了强大的资源搜索功能,使您可以快速查找特定的资源。 安装 K9s 可用于 Linux、macOS 以及 Windows 平台 地址:https://github.com/derailed/k9s Linux12[root@localhost ~]# wget https://github.com/derailed/k9s/releases/download/v0.21.7/k9s_Linux_x86_64.tar.gz[root@localhost ~]# tar -zxf k9s_Linux_x86_64.tar.gz -C /usr/...
kubectl port-forward
kubectl port-forward 是 Kubernetes 提供的一个命令行工具,它允许你从本地机器转发一个或多个端口到 Kubernetes 集群中的 Pod。这个功能在开发和调试应用程序时非常有用,因为它可以让你直接访问集群中的服务,而不需要通过 Kubernetes 的服务发现和负载均衡机制。 使用 kubectl port-forward 的一些常见场景包括: 快速访问服务:当开发者需要迅速检查集群内部署的服务是否正常运行时,他们可以直接将该服务的端口转发到本地机器来访问。 调试应用:如果开发者需要调试集群内部的应用程序,在该应用程序没有暴露为服务或者没有外部IP时,port-forward 可以提供一个快速的解决方案。 数据库调试:对于涉及数据库的服务,port-forward 允许开发者使用本地数据库客户端工具连接到集群中的数据库 Pod,进行调试和查询操作。 基本语法为: 1kubectl port-forward TYPE/NAME [options] LOCAL_PORT:REMOTE_PORT TYPE/NAME 是指定的资源类型和名称,例如 ...
VPA和CA
VPAKubernetes VPA(Vertical Pod Autoscaler)可以理解为对单个服务资源进行扩容,如CPU、内存之类。它一般应用于一些中心化的单体应用,且无法对其进行部 署多份副本的场景,如 Prometheus 或 Jenkins 这类垂直 Pod 应用自动扩缩容。 VPA 会基于 Pod 的 资源使用情况自动为集群设置资源占用的限制,从而让集群将 Pod 调度到有足够资源的最佳节点上。VPA 也会保持最初容器定义中资源 request 和 limit 的占比。 当控制器检测到一个Pod负载过高时,这时会对当前Pod进行终止,接着对Pod的CPU或内存进行扩容,最后重建Pod,此时Pod可能在任何一个节点进行重建。 它与HPA的扩容机制是完全不一样的,VPA扩容过程中将无法正常提供服务,也因此它使用的场景相比HPA来说,要少的多。 安装vpa1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859...
标签,污点&容忍以及驱逐维护
污点与容忍 亲和性/反亲和性无论是硬策略还是软策略方式,都是调度 pod 到预期节点上,而Taints恰好与之相反,如果一个节点标记为 Taints ,除非 pod 也被标识为可以容忍污点节点,否则该 Taints 节点不会被调度 pod。 污点:taints 容忍:tolerations 污点策略污点策略有以下选项: NoSchedule:表示 pod 不会被调度到标记为 taints 的节点 PreferNoSchedule:NoSchedule 的软策略版本,表示尽量不调度到污点节点上去 NoExecute:该选项意味着一旦 Taint 生效,如该节点内正在运行的 pod 没有对应 Tolerate 设置,会直接被逐出 污点 taint 标记节点的命令如下: 12$ kubectl taint nodes node02 test=node02:NoSchedulenode "node02" tainted 容忍上面的命名将 node02 节点标记为了污点,影响策略是 NoSchedule,只会影响新的 pod 调度,如果仍然希望...
Pod/Node亲和性和反亲和性部署
参考:https://cloud.tencent.com/developer/article/1746649 Kubernetes K8S之Node节点亲和性与反亲和性以及Pod亲和性与反亲和性详解与示例 主机配置规划 服务器名称(hostname) 系统版本 配置 内网IP 外网IP(模拟) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-node01 CentOS7.7 2C/4G/20G 172.16.1.111 10.0.0.111 k8s-node02 CentOS7.7 2C/4G/20G 172.16.1.112 10.0.0.112 亲和性和反亲和性nodeSelector提供了一种非常简单的方法,将pods约束到具有特定标签的节点。而亲和性/反亲和性极大地扩展了可表达的约束类型。关键的增强是: 1、亲和性/反亲和性语言更具表达性。除了使用逻辑AND操作创建的精确匹配之外,该语言还提供了...
DNS最佳实践及问题排查
转自: https://help.aliyun.com/document_detail/172339.html#11 DNS最佳实践优化域名解析请求DNS域名解析请求是Kubernetes最高频的网络行为之一,其中很多请求是可以优化和避免的。您可以通过以下方式优化域名解析请求: (推荐)使用连接池:当一个容器应用需要频繁请求另一服务时,推荐使用连接池。连接池可以将请求上游服务的链接缓存在内存中,避免每次访问时域名解析和TCP建连的开销。 使用DNS缓存: (推荐)当您的应用无法改造成通过连接池连接另一服务时,可以考虑在应用侧缓存DNS解析结果,具体操作,请参见使用节点DNS缓存NodeLocal DNSCache。 如果NodeLocal DNSCache无法适用的,可以在容器内置NSCD(Name Service Cache Daemon)缓存。关于如何使用NSCD缓存,请参见在Kubernetes集群中使用NSCD。 优化resolv.conf文件:由于resolv.conf文件中ndots和search两个参数的机制作用,容器内配置域名的不同写法决定了域名解析的效...
Dckr-向导式构建工具
Dckr<谨供参考> 最近发现个好东西-Dckr : 一款基于Docker的容器配置及编排的向导式构建工具(支持Docker、Compose、Kubernets、Rancher的资源文件向导式构建) 引自官方: 12345678910111213通过它,你可以轻松完成以下操作: 借助语义化UI向导式构建Dockerfile、docker-compose.yaml、Kubernetes资源文件、Rancher Chart。 支持docker-compose.yaml向Kubernetes资源文件的转换。 支持docker-compose.yaml或Kubernetest(Helm Chart)向Rancher Chart的转换。它的存在意义: 通过语义化UI向导式的指引你去构建相关容器配置、编排文件,降低了你的学习成本。 通过转换功能,能轻松地将不同容器产品的配置文件进行相互转换,极大地提高了你的工作效率。 通过它进行构建的YAML文件是符合规范的,让你摆脱编写YAML文件因缩进等格式问题带来的痛苦。 通过它你可以轻松对相关...
Endpoints
k8s集群中创建一个名为hello的service,就会生成一个同名的endpoint对象,ENDPOINTS就是service关联的pod的ip地址和端口, 即动态存储pod ip地址和端口对应关系的list,Kubernetes在创建Service时,根据Service的标签选择器(Label Selector)来查找Pod,据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时,EndPoints也随之变化。Service接收到请求时,就能通过EndPoints找到请求转发的目标地址endpoint不可以用来固定podip,endpoint是随着pod的改变而改变,而非pod随着endpoint的改变而改变 手动创建 Endpoint 创建service: 略 创建一个 endpoint.yaml 文件,内容如下(注意替换ip为你容器访问ip(pod ip)): 12345678910apiVersion: v1kind: Endpointsmetadata: name: nginxsubsets: - addresses: - i...
HPA(水平伸缩)和PodDisruptionBudget(干扰预算)
HPA我们可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容,但是这显然不符合Kubernetes的定位目标–自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况,实现pod数量的自动调整,于是就产生了Horizontal Pod Autoscaler(HPA)这种控制器。 HPA可以获取每个Pod利用率,然后和HPA中定义的指标进行对比,同时计算出需要伸缩的具体值,最后实现Pod的数量的调整。其实HPA与之前的Deployment一样,也属于一种Kubernetes资源对象,它通过追踪分析RC控制的所有目标Pod的负载变化情况,来确定是否需要针对性地调整目标Pod的副本数,这是HPA的实现原理 注: 在 K8S 1.18之前,HPA 扩容是无法调整灵敏度的 对于缩容,由 kube-controller-manager 的 --horizontal-pod-autoscaler-downscale-stabilization-window 参数控制缩容时间窗口,默认 5 分钟,即负载减小后至少需要等 5 分钟才会缩容。 对于扩容,由 ...
