k8s资源对象-ingress通俗理解及配置使用

理论

什么是ingress
简单理解，ingress就是将pod所提供的服务暴露出来，能够让k8s集群外部访问到对应的服务。
为什么要使用ingress？
除了可以使用ingress。我目前使用过的还有nodeport，nodeport直接映射集群中每台主机的端口，可以通过访问集群中任意一台主机的地址+端口来访问对应的服务。
用nodeport不好么？多出了这么个东西是为了解决什么问题？
我仔细琢磨了下，k8s的设计思想就是将整个k8s集群作为逻辑上的一台主机，每个pod相当于一个或一组相关进程。
对，我们一定可以这么理解：nodeport就相当于在Linux主机上的服务进程端口，用户访问时直接通过IP+端口可以访问；那么ingress（或许叫做ingress-controller更合适）就是一个nginx之类的反向代理，将需要反向代理的服务全部都塞到配置文件里，我们只需要访问ingress暴露出来的端口就可以（通过不同域名来区分，或者是根据url来区分）。
但是和Linux主机所不同的是：就算我们不是很理解，但是要知道一个事实，Linux主机上的服务进程端口就算用nginx做统一管理，统一反向代理；但是它自身不会减少主机暴露的端口，只是它会对用户层面隐藏掉。但是ingress就不一样了，它是真正减少暴露宿主机的端口的；我们创建pod提供服务，肯定要暴露出来端口啊，它是怎么做到的？这是当然，只不过笔者能力有限，我尝试着这样说明一下：创建pod提供必需要暴露端口，这是进程之间通信也好，用户访问也好，都需要的。只不过在k8s中，有了service这个概念，service的端口开放，但是不占用宿主机的，如果我们不做别的操作，它只能在集群内部进行访问。
ingress就是如此，接受到请求，根据配置转发，反向代理到后面的service
如上理论个人理解，不官方

撸部署撸配置

之前称呼的ingress有些不严谨，ingress相当于使用nginx的server段，而ingress-controller可以类比nginx自身，而ingress-controller有很多中，Nginx，HAProxy，Envoy，Traefik，只是nginx比较广泛，好理解。

部署一个ingress-nginx

官方yaml文件地址：https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
    verbs:
      - update

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 101
            runAsUser: 101
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown

---

apiVersion: v1
kind: LimitRange
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  limits:
  - min:
      memory: 90Mi
      cpu: 100m
    type: Container

配置很多，原理很简单，这个Pod本身，就是一个监听Ingress对象以及它所代理的服务变化的控制器。当一个新的Ingress对象由用户创建后，nginx-ingress-controller就会根据Ingress对象里定义的内容，生成副本对应的Nginx配置文件（/etc/nginx/nginx.conf），并使用这个配置文件启动一个Nginx服务。

接下来的配置就相当于，我们创建了一个nginx，接下来要为它指定访问的入口，也就是定义service

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
      nodePort: 80
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
      nodePort: 443
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

如配置所写：我将宿主机的80映射到容器的默认80，443对应443，很方便

好，那再接下来，我们有了nginx反向代理，我们要配置它代理谁了；我这里又个后端的私有服务端口8080

不过在这之前，我想配置https了，我下面说说，https和http分别的配置

https：

? 首先将已有的crt和key文件创建成secret对象，以便使用

? ingress-secret.yml

apiVersion: v1
data:
  tls.crt: UVVITUFHR0dHaDBkSEE2Ckx5OXZZM053TG1kdlpHRmtaS
  #你的crt经过base64编码之后放到这里，我这只是示范，注意空格换行都不要。
  #cat key  | base64 | tr ‘\n‘ ‘ ‘ | sed  ‘s/ //g‘
  tls.key: xVWE3Q2FDbjNobis4QzkxM2FyOUNSNXZ
  #同上，值得注意的是tls.crt和tls.key这个字段，我之前以为只是一个名称，可以改写。但是这两个字段是关键词，死的，不能动。
kind: Secret
metadata:
  name: ingress-secret
  namespace: default
  #注意名称空间，要和待会我创建的ingress在一个名称空间内，否则不生效
type: kubernetes.io/tls

? ingress.yml，创建ingress，和提供服务的pod的service端口必须对应。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: keycloak
  namespace: default
spec:
  tls:
    - hosts:
      - key.123456.com
      secretName: ingress-secret
      #之前的secretname字段必须相同
  rules:
  - host: key.123456.com
    http:
      paths:
      - backend:
          serviceName: keycloak
          servicePort: 8080

自行使用apply进行创建，并查看验证,严格注意名称空间

http:文件示例

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ***
  namespace: kube-system
spec:
  rules:
  - host: dashboard.mritd.me
    http:
      paths:
      - backend:
          serviceName: kubernetes-dashboard
          servicePort: 80
  - host: kibana.mritd.me
    http:
      paths:
      - backend:
          serviceName: kibana-logging
          servicePort: 5601

k8s资源对象-ingress通俗理解及配置使用

理论

撸部署撸配置

相关推荐