Kubernetes Headless Service

1. Headless Service

headless service 需要将 spec.clusterIP 设置成 None。

因为没有ClusterIP,kube-proxy 并不处理此类服务,因为没有load balancing或 proxy 代理设置,在访问服务的时候回返回后端的全部的Pods IP地址,主要用于开发者自己根据pods进行负载均衡器的开发(设置了selector) 或 StatefulSet.

2. Test Headless Service With selectors

$cat deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2 # tells deployment to run 2 pods matching the template
  template: # create pods using pod definition in this template
    metadata:
      # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is
      # generated from the deployment name
      labels:
        app: nginx_test
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
$ cat headless_service.yaml
kind: Service
apiVersion: v1
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx_test
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  clusterIP: None

通过dns访问,会返回后端pods的列表

登录到Cluster的内部pod

nslookup nginx-service
nslookup: can‘t resolve ‘(null)‘: Name does not resolve

Name:      nginx-service
Address 1: 10.10.23.36
Address 2: 10.10.23.39

原文地址:https://www.cnblogs.com/vincenshen/p/9642156.html

时间: 2024-08-01 08:20:40

Kubernetes Headless Service的相关文章

kubernetes学习Service之headless

一.首先说headless Service和普通Service的区别headless不分配clusterIPheadless service下的Pod有DNS地址,可以通过Pod的DNS地址解析到Pod的IP地址普通的service下的Pod没有DNS,只能通过svc的DNS解析到svc的clusterIP Service的ClusterIP工作原理:一个service可能对应一组endpoints(所有pod的地址+端口),client访问ClusterIP,通过iptables或者ipvs转

Kubernetes(7) Service & Network (advanced)

从上一章节我们做了一个Service提供服务给单节点Redis数据库的实验.在这一章我们要深入Service中去,来弄清Service的工作原理. 1 Kubernetes 如何向客户端提供网络功能 Kubernetes中有三种网络类型:Node Network,Pod Network 和 Cluster Network(virutal IP).其中Node 和 Pod Network 都是实实在在的网络设备上的IP,Cluster Network (Service Network) 则是虚拟的

深入了解kubernetes 中Service服务的内在逻辑

背景深入了解Service服务的内在逻辑 Servicek8s中service是一个面向微服务架构的设计,它从k8s本身解决了容器集群的负载均衡,并开放式地支持了用户所需要的各种负载均衡方案和使用场景. 通常,一个service被创建后会在集群中创建相应的endpoints,随后,controller-manager中的endpointsController会去检查并向该endpoints填入关于这个service,符合下述所有条件的后端端点(即pod): 相同的namespace:pod的la

statefulSet + headless service 学习记录

1.statefulset.yaml apiVersion: apps/v1kind: StatefulSetmetadata:   name: webspec:    serviceName: "nginx"    replicas: 2    selector:     matchLabels:        app: nginx    template:        metadata:             labels:                  app: ngin

Kubernetes Nginx Service发现并访问

启动nginx service: kubectl run nginx --image=nginx 查看service状态: kubectl get services 发现只有kubernets service: kubernetes   10.254.0.1     <none>        443/TCP   1d 使用如下命令暴露nginx: kubectl expose deployment nginx --port=80 --type=LoadBalancer 再次查看service

kubernetes的Service Account

Service account作用Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务. Service account使用场景运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务.Service Account它并不是给kubernetes集群的用户使用的,而是给pod里面的进程使用的,它为pod提供必要的身份认证. 与User account区别(1)User account是为人设计的,而se

Kubernetes学习 Service + Rolling Update(三)

四.外网如何访问Service 除了 Cluster 内部可以访问 Service,很多情况下我们也希望应用的 Service 能够暴露给 Cluster 外部.Kubernetes 提供多种类型的 Service,默认是 Cluster IP.     (1)Cluster IP Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内部的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 CLuster IP. (2

kubernetes的Service Account和secret

系列目录 Service Account Service Account概念的引入是基于这样的使用场景:运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务.Service Account它并不是给kubernetes集群的用户使用的,而是给pod里面的进程使用的,它为pod提供必要的身份认证. kubectl get sa --all-namespaces NAMESPACE NAME SECRETS AGE default build-robo

kubernetes 学习 service相关

1:         service有什么用? 直接通过Pod的IP地址和端口号可以访问容器应用,但是pod的IP地址是不可靠的,比如POD出现故障后,有可能在另外一个NOde上启动,这样Pod的IP地址就发生变化. 另外,如果容器本事是分布式的部署方式,通过多个实例一起提供服务,那么需要一个负载均衡器. k8s的service就是解决以上问题的.     关键配置: clusterIP:  给servcie分配一个虚拟IP. NodeIP:    让service和Node拥有同样的IP. 2