简述Kubernetes Service类型？

来源：蜘蛛抓取(WebSpider) 时间：2022-05-17 03:34 标签： b的类型

在默认情况下，一个Pod在哪个Node节点上运行，是由scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的，但是在实际使用中，这并不满足要求，因为在很多情况下，我们想控制某些Pod在某些某些节点上，这就要求Kubernetes能对Pod进行调度，Kubernetes提供了四种调度方式

  • 自动调度：由scheduler计算得出

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上，注意，这里所说的调度是强制的，这意味着即使调度的Node不存在，也会向上面进行调度，只不过pod运行失败而已

如下，查看可以发现此时已经调度到node2节点上了

首先给node1和node2节点打不同的标签

如下，可以看到，pod如愿被调度到node2节点上

最后使用如下命令删除资源

Kubernetes是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

　　Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。

同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征：

  1. 拥有一个唯一指定的名字
  2. 能够提供某种远程服务能力
  3. 被映射到了提供这种服务能力的一组容器应用上

　　Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们对服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，我们不用为了服务的IP地址的变化问题而进行修复。

　　容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label

Pod运行在一个称之为节点（Node）的环境中，节点可以是物理机，也可以是虚拟机，通过一个节点运行几百个Pod；其次每个Pod里运行着一个特殊的称之为Pause的容器，其他容器则为业务容器，所有业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间的通信和交互更为高效，因此在设计之初可以将一组密切相关联的服务进程放入同一个Pod中。

　　在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

　　在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

  1. 目标Pod需要运行的副本数量（Replicas）
  2. 要监控的目标Pod标签（Label）

　　在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标，这个过程完全是自动化。

  • 节省资源，优化硬件资源的使用
  • 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
  • 可扩展: 模块化, 插件化, 可挂载, 可组合
  • 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

k8s 我们已经从 NameSpace、Pod、PodController到Volumn都介绍过了，相信看完的小伙伴们也会很有收获的~那么今天我们继续来到k8s的课堂，这节我们将要来说下 k8S 搭建完服务后如何访问!

首先我们要清楚什么是Service 和 Ingress。简单来说，这两个组件都是用来做流量负载的。那么什么又是流量负载呢?当我们在集群内部已经通过 pod 部署了我们的应用服务，那么下一步要干啥?那就是让用户访问到我们的应用服务，这个才是最重要的，不然你部署完了，用户却访问不了，那岂不是无用功~

在 k8s 中，pod 是应用程序的载体，我们可以通过 pod的 IP 来访问我们的应用程序，但是我们已经清楚了 pod 是具有生命周期的，一旦 pod 出现问题，pod控制器将会将pod销毁进行重新创建。那么这个时候 pod 的Ip就会发生变化，因此利用 pod IP 访问应用程序的方式直接 pass了，那么为了解决这个问题，k8s 引入了 Service 的资源概念，通过这个资源，可以整合多个pod，提供一个统一的入口地址，通过访问 Service 的入口地址就能访问到后面的 pod服务!

Service不是凭空出现的，不知道你是否还记得 Node 节点上的关键组件 kube-proxy!关键点来了哦~我们看个老图回忆一下：

这张图有看过之前的博文都不会陌生，是的!kube-proxy 在这里面起到了关键性的作用，每个 Node 节点上都运行着一个 kube-proxy 服务进程，当创建 Service 的时候会通过 api-server 向 etc写入创建的 service 的信息，而 kube-proxy 会基于监听的机制发现这种 Service 的变动，然后 它会将最新的Service信息转换成对应的访问规则

到这里，应该对Service有个大概的概念，起码知道了它的用处，接下来我们不妨更加深入的了解一下~

通过创建后我们还需要在我们电脑的本地 hosts 添加域名映射：

然后在网页上通过 域名+nodePort 的方式就可以访问到了

到这里我们就实现了Ingress 的访问方式!

我要回帖

更多关于 b的类型 的文章

 

随机推荐