k8s 之service资源介绍(三)

kubernetes service资源

apiVersion: v1
kind: Service
metadata:
    name: kubia
spec:
    ports:
    - port: 80
       targetPort: 8080
    selector:
       app: kubia

kubectl get svc

kubectl exec kubia-id -- curl -s http://service_ip

双横缸代表着kubectl 命令项的结束,下面的是容器内部执行的命令

apiVersion: v1
kind: Service
metadata:
    name: kubia
spec:
    sessionAffinity: ClientIP

sessionAffinity属性默认为None,ClientIP 是保证特定客户端产生的请求每次都指向同一个pod

apiVersion: v1
kind: Service
metadata:
    name: kubia
spec:
    ports:
    - name: http
       port: 80
       targetPort: 8080
    - name: https
       port: 443
       target: 8443
    selector:
       app: kubia

标签选择器应用于整个服务,不能对每个端口做单独的配置

上面是采用端口号进行映射,还有一种方式给端口命名,这样在做映射的时候直接指向名称。好处是pod的端口随便改,而不用改service的配置如下:

kind: Pod
metadata:
   name: kubia
spec:
   containers:
   - name: kubia
      ports:
          - name: http
             containerPort: 8080
          - name: https
             containerPort: 8443

apiVersion: v1
kind: Service
spec:
    ports:
    - name: http
       port: 80
       targetPort: http
    - name: https
       port: 443
       targetPort: https
     selector:
         app: kubia

kubectl delete po --all 删除所有pod ,而不管pod的id

kubectl delete all --all all代表所有资源,--all代表所有资源对象

backend-database.default.svc.cluster.local

backend-database 服务名称

default 命名空间

svc.cluaster.local是在所有集群本地服务名称中使用的可配置集群域后缀

kubectl exec -ti kubia-3inly bash 运行bash很像 docker exec -ti id bash

不要ping kubernetes中创建的服务名称,这是因为服务的ip是一个虚拟的IP,只有在与服务端口结合时才有意义

endpoint资源

kubernetes service不仅可以暴露pod给外部,同样也可以把外部服务创建为服务让内部pod进行访问。服务并不是和pod直接相连的,有一种资源-endpoint介于两者之间。

endpoint资源就是暴露一个服务的IP地址和端口的列表,endpoint资源和其他kubernetes资源一样,所以可以使用kubectl info 来获取它的基本信息

kubectl describe svc kubia 执行此命令能看到endpoint资源

kubectl get endpoints kubia

我知道在创建service时定义了selector pod选择器,但在重定向传入连接时不会直接使用它。

选择器用于构建IP和端口列表,然后存储在EndPoint资源中。当客户端连接到服务时,服务代理选择这些IP和端口对中的一个,并将传入连接重定向到改位置监听的服务器。

EndPoint是一个单独的资源,而不是service的属性,所以我们可以单独的创建endpoint资源对象。

我们在创建service时不声明pod选择器就不会创建endpoint

apiVersion: v1
kind: Service
metadata:
    name: external-service
spec:
    ports:
    - port: 80

这里并没有定义selector

下面我们手动创建endpoint

apiVersion: v1
kind: Endpoints
metadata:
    name: external-service   这里的名称一定和service的一致
subsets:
-   addresses:
    - ip: 1.1.1.1
    - ip: 2.2.2.2
ports:
-   port: 80 这里的port是endpoint的目标端口,是service中的targetPort

以上就做了一个将外部服务通过service让内部pod可以访问。

还有一种简单的方式,给外部服务创建一个别名服务。

apiVersion: v1
kind: Service
matedata:
    name: external-service
spec:
    type: ExternalName     代码的type被设置成ExternalName
    externalName:  someapi.somecompany.com 实际服务的完全限定名
    ports:
      - port: 80

内部就可以使用external-service来访问服务了

kubectl get po --all-namespaces 非常好用

原文地址:https://www.cnblogs.com/zhming26/p/11719499.html

时间: 2024-08-30 18:20:16

k8s 之service资源介绍(三)的相关文章

Puppet默认资源和虚拟资源介绍(三十一)

puppet的默认资源 默认资源可以为资源初始化属性和值,通常默认资源声明在site.pp文件首部,代码如下: [[email protected] ~]# cat site.pp  Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin'} 声明默认资源注意事项如下: 1.声明默认资源时首字母需要大写,如exec声明默认资源Exec.package声明默认资源Package等. 2.如果声明资源有一个名称空间资源"::",它的每个环节都需要首

k8s无脑系列(三)-NFS存储(简单版本)

k8s无脑系列(三)-NFS存储(简单版本) 1.概念 搞清楚pv,pvc pv = PersistentVolume 持久化存储控制器,面向集群而不是namespace. pvc = PersistentVolumeClaim 对接pod与pv, 关系,官方说明 A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the Persisten

linux程序分析工具介绍(三)——sar

本文要介绍的sar,是linux下用来分析系统本身运行情况的非常有用的工具.我们知道,程序在操作系统上要运行,要关注的点不外乎内存,CPU和IO(包括磁盘IO和网络IO).我们的应用程序在操作系统中运行前,我们需要了解系统当前的内存,cpu和IO的使用状况,还需要明白我们的应用程序运行时自身所需要的内存,cpu和IO资源的情况.只有操作系统剩余的内存,cpu和IO资源能够满足应用程序所需要的,才能保证应用程序在操作系统中正常的运行.sar就是用来帮助我们了解操作系统当前内存,cpu和IO等资源的

[JAVA_开课吧资源]第三周 常用类库、异常处理

主题一 常用类库 » 类库中常用的包 Java类库中的类和接口大多封装在特定的包里,每个包具有自己的功能. [请点击查看更多内容 转自CSDN博客XXX的专栏] » Object类的一些常用方法 hashCode:public int hashCode()返回该对象的哈希码值.支持该方法是为哈希表提供一些优点,例如,java.util.Hashtable 提供的哈希表 equals:public boolean equals(Object obj)指示某个其他对象是否与此对象“相等” toStr

k8s通过service访问pod(五)--技术流ken

service 每个 Pod 都有自己的 IP 地址.当 controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址.这样就产生了一个问题: 如果一组 Pod 对外提供服务(比如 HTTP),它们的 IP 很有可能发生变化,那么客户端如何找到并访问这个服务呢? Kubernetes 给出的解决方案是 Service. 创建 Service Kubernetes Service 从逻辑上代表了一组 Pod,具体是哪些 Pod 则是由 label 来挑选.S

如何做k8s worker节点资源预留?

资源预留必要性 以常见的kubeadm安装的k8s集群来说,默认情况下kubelet没有配置kube-reserverd和system-reserverd资源预留.worker node上的pod负载,理论上可以使用该节点服务器上的所有cpu和内存资源.比如某个deployment controller管理的pod存在bug,运行时无法正常释放内存,那么该worker node上的kubelet进程最终会抢占不到足够的内存,无法向kube-apiserver同步心跳状态,该worker node

puppet进阶指南——service资源详解

service资源 通过service资源不但可以启动,重启和关闭程序的守护进程,监控进程状态,还可以将守护进程加入到自启动中. 1.service资源常用属性 service {'资源标题': binary enable ensure hasrestart hasstatus name path pattern restart start status stop provider } ◆ enable:指定服务在开机的时候是否启动,可以设置true和false. ◆ ensure:是否运行服务

Lucene.Net 2.3.1开发介绍 —— 三、索引(五)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(五) 话接上篇,继续来说权重对排序的影响.从上面的4个测试,只能说是有个直观的理解了.“哦,是!调整权重是能影响排序了,但是好像没办法来分析到底怎么调啊!”.似乎是这样,现在需要把问题放大,加大索引的内容.到博客园新闻区,用zzk找了4篇内容包含“测试”的文章.代码变成 2.1.5 代码2.1.5  1using System;  2using System.Collections.Generic;  3using Lucene.N

Lucene.Net 2.3.1开发介绍 —— 三、索引(四)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(四) 4.索引对搜索排序的影响 搜索的时候,同一个搜索关键字和同一份索引,决定了一个结果,不但决定了结果的集合,也确定了结果的顺序.那个这个结果是怎么得出来的?这个顺序又是怎么排的呢?这两个问题不是本节讨论的重点,但是这两个问题却关系到本节要讨论的,索引对结果的影响问题.在不使用字段排序的情况下,Lucene.Net默认是按文档的得分来排序的,这个公式看着很复杂,感觉像是大学时高数书上的那些个公式,其实说清楚了也简单. 关于文档排序