文档章节

Kubernetes(五) - Service

喵了_个咪
 喵了_个咪
发布于 06/19 10:15
字数 1502
阅读 336
收藏 1

Kubernetes解决的另外一个痛点就是服务发现,服务发现机制和容器开放访问都是通过Service来实现的,把Deployment和Service关联起来只需要Label标签相同就可以关联起来形成负载均衡,基于kuberneres的DNS服务我们只需要访问Service的名字就能以负载的方式访问到各个容器

Kubernetes官方文档:https://kubernetes.io/docs/reference/

Kubernetes官方Git地址:https://github.com/kubernetes/kubernetes

PS:本系列中使用 KubernetesV1.8 RancherV1.6.14

1. Service的三种类型

Service有三种类型:

  • ClusterIP:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP 常用于内部程序互相的访问,比如Gitlab需要访问Redis的postgresql,但是是内部使用的不需要外部访问,这个时候用ClusterIP就比较合适

  • NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以通过<NodeIP>:NodePort来访问改服务 当我们的Gitlab需要提供访问,可以使用NodePort指定一个端口释放服务,然后外层负载均衡映射就可以在外部访问,或者直接访问对应的端口

PS:NodePort方式暴露服务的端口的默认范围(30000-32767)如果需要修改则在apiserver的启动命令里面添加如下参数 –service-node-port-range=1-65535

  • LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到<NodeIP>:NodePort LoadBalancer是NodePort的升级版本,相当于和cloud provider结合不需要手动指定

我们经常使用的还是上面前两种方式,我们先创建一个nginx-deployment镜像2个Pod以便于接下来的使用

> vim nginx-deployment.yaml

apiVersion: extensions/v1beta1                  # K8S对应的API版本
kind: Deployment                                # 对应的类型
metadata:
  name: nginx-deployment
  labels:
    name: nginx-deployment
spec:
  replicas: 2                                   # 镜像副本数量
  template:
    metadata:
      labels:                                   # 容器的标签 可和service关联
        app: nginx
    spec:
      containers:
        - name: nginx                          # 容器名和镜像
          image: nginx
          imagePullPolicy: Always

> kubectl create -f nginx-deployment.yaml

我们分别修改一下对应的输出

> echo nginx1 > /usr/share/nginx/html/index.html
> echo nginx2 > /usr/share/nginx/html/index.html

安装好ping 和 curl

> apt-get update
> apt-get install curl iputils-ping

2. ClusterIP

> vim test-clusterip-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: test-clusterip-service             # 名称
  labels:
    name: test-clusterip-service
spec:
  type: ClusterIP                               # 开发端口的类型
  selector:                                     # service负载的容器需要有同样的labels
    app: nginx
  ports:
  - port: 80                                    # 通过service来访问的端口
    targetPort: 80                              # 对应容器的端口
> kubectl create -f test-clusterip-service.yaml
service "test-clusterip-service" created
> kubectl get service
NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes               ClusterIP   10.43.0.1      <none>        443/TCP   12d
test-clusterip-service   ClusterIP   10.43.202.97   <none>        80/TCP    18s

应为selector关联上了Deployment的Label所以直接访问是可以访问到的具体nginx镜像内,而且应为是两个Pod所以是负载均衡之前我们修改了输出多次访问可以看到不一样的结果,基于Kube-DNS也可以使用Service名称进行访问

root@nginx-deployment-68fcbc9696-wbgxr:/usr/share/nginx/html# curl 10.43.202.97
nginx2
root@nginx-deployment-68fcbc9696-wbgxr:/usr/share/nginx/html# curl test-clusterip-service
nginx1

3. NodePort

NodePort设计出来的主要目的就是对外部放出服务,也就是被外部能够访问到,

> vim test-nodeport-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: test-nodeport-service             # 名称
  labels:
    name: test-nodeport-service
spec:
  type: NodePort                               # 开发端口的类型
  selector:                                     # service负载的容器需要有同样的labels
    app: nginx
  ports:
  - port: 80                                    # 通过service来访问的端口
    targetPort: 80                              # 对应容器的端口
    nodePort: 30080                             # 对应需要放到宿主机IP上的端口

> kubectl create -f test-nodeport-service.yaml
service "test-nodeport-service" created
> kubectl get service
NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes               ClusterIP   10.43.0.1      <none>        443/TCP        12d
test-clusterip-service   ClusterIP   10.43.202.97   <none>        80/TCP         14m
test-nodeport-service    NodePort    10.43.101.60   <none>        80:30080/TCP   5s

此时在宿主机上的30080端口就可以访问到我们的两个Nginx容器了,如果机器绑定的有IP的话就可以直接访问或者在使用负载均衡对外放出服务

只有在KUbernetes中才会受到Kube-DNS的影响,在宿主机上无法使用test-nodeport-service访问Service只能通过NodePort进行访问

[root@k8s-m ~]# curl 127.0.0.1:30080
nginx2
[root@k8s-m ~]# curl 127.0.0.1:30080
nginx1

4. Ingress

Service主要是处理4层TCP负载,但是往往对外需要放出HTTP七层协议的服务,一般我们在一套集群下如果有多个HTTP服务会使用Nginx来统一接受80端口的数据然后通过域名或者是访问路径来选择不同的服务,Ingress就是解决这个问题诞生的,Ingress可以和Service结合对80端口的访问更具域名的过滤和访问路径的过滤路由到对应的service,我们一起看几个例子:

foo.bar.com -> 172.168.0.128 -> / foo    nginx:80
                                / bar    nginx:80
> vim ing.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: nginx
          servicePort: 80
      - path: /bar
        backend:
          serviceName: nginx
          servicePort: 80

> kubectl create -f ing.yaml
> kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -
          foo.bar.com
          /foo          nginx:80
          /bar          nginx:80
foo.bar.com --|                 |-> foo.bar.com nginx:80
              | 172.168.0.128   |
bar.foo.com --|                 |-> bar.foo.com nginx:80
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80

支持TLS需要使用Secret预先配置好对应的证书

apiVersion: v1
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
kind: Secret
metadata:
  name: testsecret
  namespace: default
type: Opaque
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: no-rules-map
spec:
  tls:
  - secretName: testsecret
  backend:
    serviceName: nginx
    servicePort: 80

使用Ingress能实现部分功能,但是笔者推荐使用网关服务(比如kong)来进行处理会更具灵活功能更下强大可控

小技巧

  • 跨namespace访问Service 到这里我们还没有展开说NameSpace,NameSpace隔离了资源,比如你在A中不能创建两个名字一样的Service(Kubernetes其他资源同理),但是创建出一个NameSpace的是可以创建名字为Nginx的Service的 这个时候你在A空间中访问nginx-service的是A空间的容器,在B空间访问是B空间的nginx-service 但是如果需要在B空间访问A空间的Nginx-service要怎么办呢?

Kube提供在访问Service的时候末尾增加NameSpace名字进行访问,在B空间访问A的nginx-service可以使用nginx-service.A 进行访问

© 著作权归作者所有

共有 人打赏支持
喵了_个咪
粉丝 309
博文 146
码字总数 190043
作品 4
杨浦
技术主管
私信 提问
CentOS7环境部署kubenetes1.12版本五部曲之三:node节点加入

版权声明:欢迎转载,请注明出处,谢谢。 https://blog.csdn.net/boling_cavalry/article/details/83714209 本文是《CentOS7环境部署kubenetes1.12版本五部曲》系列的第三篇,上篇文章创建了...

博陵精骑
11/04
0
0
CentOS7环境部署kubenetes1.12版本五部曲之四:安装dashboard

版权声明:欢迎转载,请注明出处,谢谢。 https://blog.csdn.net/boling_cavalry/article/details/83715479 本文是《CentOS7环境部署kubenetes1.12版本五部曲》系列的第四篇,前面的实站已经...

博陵精骑
11/04
0
0
kubernetes整合istio

前言:kubernetes核心组件正常启动,kubernetes-dashboard页面正常访问 一、下载istio-我这里使用的1.0.0,https://github.com/istio/istio/releases下载适合自己系统的版本; 解压即可然后配...

WALK_MAN
10/04
0
0
服务网与Kubernetes上的Istio分5步

在本文中,我将向您展示一些基本和更高级的示例,说明如何使用Istio平台来提供部署在Kubernetes上的微服务之间的通信。按照Istio网站上的描述,它是: 一个开放的平台,用于连接,管理和保护...

xiaomin0322
07/14
0
0
Pod控制器应用进阶五(kubernetes service)

版权声明:知识就是为了传播! https://blog.csdn.net/weixin_36171533/article/details/82531866 kubernetes service是强依赖CoreDNS或者是kube-dns功能 node network节点网络 pod network ......

JESSE_JAVA
09/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

降压变换器 Buck

特点 输入输出极性相同。 工作过程 在 MOS 导通时,输入电源通过 L 和 C 滤波后向负载端提供电流;当 MOS 断开后,L 通过二极管续流,保持负载电流连续。输出电压因为占空比的作用,不会超过...

colinux
今天
1
0
Apache日志不记录访问静态文件,访问日志切割,静态元素过期时间设置

Apache配置不记录访问静态文件的日志 网站大多元素为静态文件,如图片、css、js等,这些元素可以不用记录 vhost原始配置 <VirtualHost *:80> ServerAdmin test@163.com DocumentRoo...

野雪球
今天
3
0
聊聊storm的ICommitterTridentSpout

序 本文主要研究一下storm的ICommitterTridentSpout ICommitterTridentSpout storm-core-1.2.2-sources.jar!/org/apache/storm/trident/spout/ICommitterTridentSpout.java public interface......

go4it
今天
4
0
Ubuntu常用操作

查看端口号 netstat -anp |grep 端口号 查看已使用端口情况 netstat -nultp(此处不用加端口号) netstat -anp |grep 82查看82端口的使用情况 查找被占用的端口: netstat -tln netstat -tl...

hc321
昨天
3
0
网站cdn的静态资源突然访问变的缓慢,问题排查流程

1.首先我查看了一下是否自己的网络问题,通过对比其他资源的访问速度和下载速度,确认不是 2.通过ping 和 tracert 判断cdn域名能否正常访问,(最后回想感觉这一步可以省略,因为每次最终能访...

小海bug
昨天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部