青年IT男的博客

kubernetes的service的网络类型ingress的搭建(二)

By 青年IT男 on

inrgess最新版部署（1.6.2 1.6.3 1.6.4）亲测成功

default-backend:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    k8s-app: default-http-backend
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissable as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: gcr.io/google_containers/defaultbackend:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: kube-system
  labels:
    k8s-app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    k8s-app: default-http-backend

controller:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ingress
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: system:ingress
rules:
- apiGroups:
  - ""
  resources: ["configmaps","secrets","endpoints","events","services"]
  verbs: ["list","watch","create","update","delete","get"]
- apiGroups:
  - ""
  - "extensions"
  resources: ["services","nodes","ingresses","pods","ingresses/status"]
  verbs: ["list","watch","create","update","delete","get"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:ingress
subjects:
  - kind: ServiceAccount
    name: ingress
    namespace: kube-system

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  labels:
    k8s-app: nginx-ingress-controller
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: nginx-ingress-controller
      annotations:
        prometheus.io/port: '10254'
        prometheus.io/scrape: 'true'
    spec:
      # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration
      # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host
      # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used
      # like with kubeadm
      hostNetwork: true
      serviceAccountName: ingress
      terminationGracePeriodSeconds: 60
      containers:
      - image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.5
        name: nginx-ingress-controller
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          timeoutSeconds: 1
        ports:
        - containerPort: 80
          hostPort: 80
        - containerPort: 443
          hostPort: 443
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
        args:
        - /nginx-ingress-controller
        - --default-backend-service=$(POD_NAMESPACE)/default-http-backend

成功后如下：

01.png

test service：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: echoheaders
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - name: echoheaders
        image: gcr.io/google_containers/echoserver:1.0
        ports:
        - containerPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: echoheaders-default
  labels:
    app: echoheaders
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30302
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoheaders

---
apiVersion: v1
kind: Service
metadata:
  name: echoheaders-default
  labels:
    app: echoheaders
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoheaders

---
apiVersion: v1
kind: Service
metadata:
  name: echoheaders-x
  labels:
    app: echoheaders
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoheaders

---
apiVersion: v1
kind: Service
metadata:
  name: echoheaders-y
  labels:
    app: echoheaders
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoheaders

02.png

ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echomap
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: echoheaders-x
          servicePort: 80  #这里的servicePort与Service 中port对应
  - host: bar.baz.com
    http:
      paths:
      - path: /bar
        backend:
          serviceName: echoheaders-y
          servicePort: 80  #这里的servicePort与Service 中port对应
      - path: /foo
        backend:
          serviceName: echoheaders-x
          servicePort: 80  #这里的servicePort与Service 中port对应

03.png

test：

curl -v http://10.39.1.45/foo -H 'host: foo.bar.com'

04.png

curl -v http://10.39.1.45/foo -H 'host: bar.baz.com'

05.png

curl -v http://10.39.1.45/bar -H 'host: bar.baz.com'

06.png

说明： 
10.39.1.45 是ingress的address，也就是ingress-controller所在的node的ip

结合ingress测试service的loadbalancer网络类型，之前一直没用过这种网络类型，更多的是用nodePort，所以想测试下 
我的集群中已经存部署好了dashboard了所以就用dashboard来测试：

我新建一个lb类型的dashboard的service

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard-1
  name: dashboard-1
  namespace: kube-system
spec:
  type: LoadBalancer
  loadBalancerIP: 10.39.1.44
  ports:
  - port: 8001
    targetPort: 9090
  selector:
    k8s-app: kubernetes-dashboard

10.39.1.44是我ingress-controller的ip（负载均衡器的ip） 
08.png

09.png

发现service的类型是LoadBalancer，但是确随机生成了NodePort：30617，之后我通过LoadBalancerip加NodePort能访问，我就猜测是否LoadBalancer类型，只能通过这个LoadBalancerIP去访问呢？ 但是由于有NodePort生成，所以我就尝试用其他node节点ip加NodePort访问，发现都是可以访问的。

kind: Ingress
metadata:
  name: test
  namespace: kube-system
spec:
  rules:
  - host: dashboard.io
    http:
      paths:
      - path: /
        backend:
          serviceName: dashboard
          servicePort: 80

10.png

总结： 
1.之前一直以为loadbanlacer网络类型就是通过loadbalancerip来访问对应的应用，而测试之后发现service的loadbalancer网络类型通过ingress（或者说是nginx）实现，实质上就是nodePort类型 
2.之前也一直以为ingress是这样的：通过ingress的yaml中的hosts／path就能直接访问到对应的service，事实是能访问到对应的service。但是，实际上需要你service中对应的pod中需要存在path的服务存在，否则会报404。 比如：一个web的应用，服务地址是：http://xxxx.xxx.xxx.xxx:8080/app, 发送请求的path就是／app，ingres.yaml中的path就定义为／app，如果你服务的地址是：http://xxxx.xxx.xxx.xxx:8080/apps，ingres.yaml中的path就定义为／app，那么就会报404.
3.注意缓存更新ingress配置后最好清空缓存
4.重新配置ingress有时未能及时生效需要稍等一会这里可能存在生成nginx配置文件需要等一段时间
转载地址：https://blog.csdn.net/u013812710/article/details/72731406

发表评论

0
You cannot copy content of this page