云原生(Cloud Native)可以认为是一套技术体系或生态,它包含2大部分:云(Cloud)和原生(Native)。云(Cloud)表示应用程序位于云中,而不是传统的数据中心;原生(Native)表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳状态运行,充分利用和发挥云平台的弹性和分布式优势。
计算、存储和网络是云时代的三大基础服务,作为新一代基础架构的 Kubernetes 也不例外。而这三者之中,网络又是一个最难掌握和最容易出问题的服务;本文通过对Kubernetes网络流量模型进行简单梳理,希望对初学者能够提供一定思路。先看一下kubernetes 总体模型:
在启用了Istio服务网格的Kubernetes集群中,缺省情况下只能在集群内部访问网格中的服务,要如何才能从外部网络访问这些服务呢? Kubernetes和Istio提供了NodePort,LoadBalancer,Kubernetes Ingress,Istio Gateway等多种外部流量入口的方式,面对这么多种方式,我们在产品部署中应该如何选择?
Kubernetes 服务发现是一个经常让我产生困惑的主题之一。本文分为两个部分:
在k8s中,pod是应用程序的载体,我们可以通过pod的ip来访问应用程序,但是pod的ip地址不是固定的,这也就意味着不方便直接采用pod的ip对服务进行访问。
这篇详细的博文探讨了 Kubernetes 网络的复杂性,提供了关于如何在容器化环境中确保高效和安全通信的见解。
Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,是Docker分布式系统的解决方案。k8s里所有的资源都可以用yaml或Json定义。
我们前面介绍过用Service做集群代理,Service一般情况下只作用于内部Pod的代理调度,就算有NodePort类型,其访问节点相对复杂,流程大概如下:
Ingress 英文翻译 进入;进入权;进食,更准确的讲就是入口,即外部流量进入k8s集群必经之口。这到大门到底有什么作用?我们如何使用Ingress?k8s又是如何进行服务发现的呢?先看一张图:
大部分概念Kubernetes官网都有详细介绍,Kubernetes中文官网 https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/
Kubernetes (k8s) 集群,默认配置好了 Nginx Ingress 控制器,用于处理南北流量的调度,即处理从外部到集群内部服务的流量。下面是对您的架构的重新组织和概述:
Kubernetes 中 Service 是 将运行在一个或一组 [Pod]上的网络应用程序公开为网络服务的方法。
最近,我开始了 Kubernetes 之旅,并且希望更好地了解其内部原理。我在这些方面做了一个演讲!
在前面的章节中我们介绍过Pod是K8s进行创建、调度管理的最小单位,在同一个Pod内的Container不会垮主机,每个Pod都有独立的Pod IP (IP per Pod)并且该Pod包含的所有容器共享一个网络协议栈(或者网络名称空间), 例如容器之间通过localhost+port可以进行相互访问。即集群中的所有Pod都处于一个扁平互通的网络空间。
1、网络的命名空间:Linux 在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命名空间中,彼此间无法通信;Docker 利用这一特性,实现不容器间的网络隔离。
最近,我开始了 Kubernetes 之旅,并且希望更好地了解其内部原理。我在这些方面做了一个演讲,这是它的博客版本。
在我们尝试了解Kubernetes之前,让我们花一点时间来澄清容器是什么,以及它们为什么如此受欢迎。毕竟,在不知道容器是什么的情况下谈论容器编排器(Kubernetes)是没有意义的。
大家好,本期微课堂介绍在新一代数字化企业云平台中对于Kubernetes的学习以及使用的总结。 本次分享分为两部分: 1.介绍Kubernetes是什么以及一些基本概念 2.介绍在新一代数字化企业云平
最近,我开始了 Kubernetes 之旅,希望更好地了解其内部。下面简单介绍下吧!
Docker的网络驱动是指在Docker引擎中实现容器网络通信的技术。它包括以下几种常见的网络驱动:
Grafana Loki 是一个水平可扩展,高可用性,多租户的日志聚合系统,Loki 是基于仅索引有关日志元数据的想法而构建的:标签(就像 Prometheus 标签一样)。日志数据本身被压缩然后并存储在对象存储(例如 S3 或 GCS)的块中,甚至存储在本地文件系统上,轻量级的索引和高度压缩的块简化了操作,并显著降低了 Loki 的成本,Loki 更适合中小团队。由于 Loki 使用和 Prometheus 类似的标签概念,所以如果你熟悉 Prometheus 那么将很容易上手,也可以直接和 Grafana 集成,只需要添加 Loki 数据源就可以开始查询日志数据了。
基于不同的业务场景中,我们该如何在 Kubernetes 生态集群中规划我们应用程序接口的访问策略呢?
Kubernetes是当今最流行的容器编排和集群管理平台之一。本博客将深入解析Kubernetes的核心架构,重点介绍主节点、工作节点和容器运行时,并探讨核心概念:Pod、Service和Namespace。通过对这些关键组件的理解,读者将掌握在Kubernetes中部署和管理应用程序的基础知识。
核心组件组成: kubectl: 客户端命令行工具,将接受的命令格式化后发送给kube-apiserver,作为整个系统的操作入口。 kube-apiserver: 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;这是kubernetes API,作为集群的统一入口,各组件协调者,以HTTPAPI提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 kube-scheduler: 资源调度,按照预定的调度策略将Pod调度到相应的机器上;它负责节点资源管理,接受来自kube-apiserver创建Pods任务,并分配到某个节点。它会根据调度算法为新创建的Pod选择一个Node节点。 kube-controller-manager: 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;它用来执行整个系统中的后台任务,包括节点状态状况、Pod个数、Pods和Service的关联等, 一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的。 etcd: 集群的主数据库,保存了整个集群的状态; etcd负责节点间的服务发现和配置共享。etcd分布式键值存储系统, 用于保持集群状态,比如Pod、Service等对象信息。 kubelet: 负责维护容器的生命周期,负责管理pods和它们上面的容器,images镜像、volumes、etc。同时也负责Volume(CVI)和网络(CNI)的管理;kubelet运行在每个计算节点上,作为agent,接受分配该节点的Pods任务及管理容器,周期性获取容器状态,反馈给kube-apiserver; kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 container runtime: 负责镜像管理以及Pod和容器的真正运行(CRI); kube-proxy: 负责为Service提供cluster内部的服务发现和负载均衡;它运行在每个计算节点上,负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。它在Node节点上实现Pod网络代理,维护网络规则和四层负载均衡工作。 docker或rocket(rkt): 运行容器。 其中: master组件包括: kube-apiserver, kube-controller-manager, kube-scheduler; Node组件包括: kubelet, kube-proxy, docker或rocket(rkt); 第三方服务:etcd
我们看到 Docker 的本质其实就是被 linux 系统机制隔离的进程,有了这样的隔离性,我们能够借以实现我们的微服务架构。
在Kubernetes中,Pods是有生命周期的。它们被创建、被终止,但不能被复活。在Kubernetes中通过ReplicationControllers动态的创建和删除Pod。然后,每一个Pod都拥有自己的IP地址,但是这些IP地址随着时间会发生变化。这会导致一个问题:如果在Kubernetes集群中,前端的Pod需要调用后端的Pod的功能,那么这些前端的Pod如何发现和跟踪后端的Pod?
在本系列文章的上一篇中,细心的读者注意到,linkerd是使用DaemonSet而不是作为挎斗(SideCar)进程安装的(关于SideCar的概念及翻译引用自Azure技术社区的文档)。在这篇文章中,我们将解释为什么这样做以及怎样做。
官方定义k8s能够对容器化软件进行部署管理,在不停机的前提下提供简单快速的发布和更新方式。换句话说,如果项目需要多机器节点的微服务架构,并且采用Docker image(镜像)进行容器化部署,那么k8s可以帮助我们屏蔽掉集群的复杂性,自动选择最优资源分配方式进行部署。在此基础上,k8s还提供简单的多实例部署及更新方案,仅需几个操作命令就可以轻松实现。
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能。但是通过对 Cilium 不同模式的切换/功能的启用,可以进一步提升 Cilium 的网络性能。具体调优项包括不限于:
通常web应用获取用户客户端的真实ip一个很常见的需求,例如将用户真实ip取到之后对用户做白名单访问限制、将用户ip记录到数据库日志中对用户的操作做审计等等
Podman 原来是 CRI-O 项目的一部分,后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似,不同的是 Podman 没有 daemon。以前使用 Docker CLI 的时候,Docker CLI 会通过 gRPC API 去跟 Docker Engine 说「我要启动一个容器」,然后 Docker Engine 才会通过 OCI Container runtime(默认是 runc)来启动一个容器。这就意味着容器的进程不可能是 Docker CLI 的子进程,而是 Docker Engine 的子进程。
我们这个系列的文章一直都在学习和掌握K8S各种组成部分在集群里的角色、作用和使用场景,那么针对今天这个主题任务「给K8S上的Web服务做域名解析」你觉得应该使用什么组件来完成呢?
Kubernetes已经成为在服务中编排容器和服务的实际方法。但是我们如何让集群外部的服务访问集群内部的内容呢?Kubernetes附带了Ingress API对象,用于管理对集群内服务的外部访问。
CVE-2018-1002105 是一个 k8s 提权漏洞,该漏洞允许攻击者在拥有 pod 权限的情况下,提升至 API Server 权限,当拥有 API Server 权限后,也就不难逃逸到宿主机了。
Pod 是在 Kubernetes 中创建和管理的、最小的可部署的计算单元,是最重要的对象之一。一个 Pod 中包含一个或多个容器,这些容器在 Pod 中能够共享网络、存储等环境。
当我们将kubernetes的应用部署完之后,就需要对外发布服务的访问地址。kubernetes 将服务发布到外部访问的方式主要有: LoadBlancer Service NodePort Service Ingress
采用 NodePort 方式暴露服务面临问题是,服务一旦多起来,NodePort 在每个节点上开启的端口会及其庞大,而且难以维护;这时,我们可以能否使用一个Nginx直接对内进行转发呢?众所周知的是,Pod与Pod之间是可以互相通信的,而Pod是可以共享宿主机的网络名称空间的,也就是说当在共享网络名称空间时,Pod上所监听的就是Node上的端口。那么这又该如何实现呢?简单的实现就是使用 DaemonSet 在每个 Node 上监听 80,然后写好规则,因为 Nginx 外面绑定了宿主机 80 端口(就像 NodePort),本身又在集群内,那么向后直接转发到相应 Service IP 就行了,如下图所示:
本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看
在实际生产环境中,有些容器内应用(比如编码器)需要用到物理层面的网络资源(比如组播流)。这就要求Kubernetes中的该Pod以HOST模式来启动。以下实验了Kubernetes-HOST网络模式,并给出了一些运维建议。 1、Pod的网络 每个Pod都会默认启动一个pod-infrastructure(或pause)的容器,作为共享网络的基准容器。其他业务容器在启动之后,会将自己的网络模式指定为“"NetworkMode": "container:pause_containerID”。这样就能做到
顾名思义,Router 是路由器,Route 是路由器中配置的路由。OpenShift 中的这两个概念是为了解决从集群外部(就是从除了集群节点以外的其它地方)访问服务的需求。不晓得为什么OpenShift 要将Kubernetes 中的 Ingress 改为 Router,我倒是觉得 Ingress 名字更贴切。
现在 Docker 的流行程度越来越高,越来越多的公司使用 Docker 打包和部署项目。但是也有很多公司只是追求新技术,将以前的单体应用直接打包为镜像,代码、配置方式等各方面保持不变,使用 Docker 后,并没有带来多大的便利,反而使得配置、启动过程变得更加繁杂,更难调试。
服务网格(Service Mesh)用来描述组成这些应用程序的微服务网络以及它们之间的交互。
“容器”已成为最新的流行语之一。但是,这个词到底意味着什么呢?说起“容器”,人们通常会把它和 Docker 联系起来,Docker 是一个被定义为软件的标准化单元容器。该容器将软件和运行软件所需的环境封装到一个易于交付的单元中。
Kubernetes (通常称为 K8s) 是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统,是 Google 内部工具 Borg 的“开源版”。
虚拟集群(virtual cluster, 简称 vcluster)是在常规的 Kubernetes 集群之上运行的一个功能齐全,轻量级,隔离性良好的 Kubernetes 集群。虚拟集群的核心思想是提供运行在“真实”Kubernetes 集群之上隔离的 Kubernetes 控制平面(例如 API Server)。与完全独立的“真实“集群相比,虚拟集群没有自己的工作节点或者网络,工作负载实际上还是在底层宿主集群上调度。
Kubernetes Pod 是有生命周期的,它们可以被创建,也可以被销毁,然而一旦被销毁生命就永远结束。 通过 ReplicationController 能够动态地创建和销毁 Pod(例如,需要进行扩缩容,或者执行)。 每个 滚动升级 Pod 都会获取它自己的 IP 地址,即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题:在 Kubernetes 集群中,如果一组 Pod(称为 backend)为其它 Pod (称为 frontend)提供服务,那么那些 frontend 该如何发现,并连接到这组 Pod 中的哪些 backend 呢?
前文已经介绍过了k8s ingress的实现原理和配置,本文将介绍替代方案traefik。在开始配置之前我们先回顾一下ingress发布k8s服务的实现方案,ingress方案需要使用下列的组件:
客座撰稿人:Karen Bruner,StackRox技术专员。原文可以在这里找到。
在这篇博文中,我们回顾了Kubernetes管理前端,并讨论了这些工具是如何被构建的。
领取专属 10元无门槛券
手把手带您无忧上云