Service与Ingress

Endpoint

Endpoint 概述

在创建 Service 时会自动创建一个与之同名的 Endpoint
只有在 Endpoint 就绪列表中的Pod才可被调度，即就绪探针探测通过的Pod
通常 Endpoint 由 Service 自动创建即可
但如果需要将集群外部的服务引入到k8s集群内部中来，则可以使用手动创建 Endpoint 这种方式来实现
- Endpoint 的端点直接指向外部服务的IP和端口号，而后再在前面创建 Service；
  - 但是集群外部服务出现问题不能实现自动下线？TCP无法连接就会自动将其下线并设为noready？

—

Endpoints Explain

apiVersion: v1
kind: Endpoint
metadata:  # 对象元数据
  name:
  namespace:
subsets:      # 端点对象的列表
- addresses:  # 处于“就绪”状态的端点地址对象列表
  - hostname  <string>  # 端点主机名
    ip <string>          # 端点的IP地址，必选字段
    nodeName <string>   # 节点主机名
    targetRef：              # 提供了该端点的对象引用
      apiVersion <string>  # 被引用对象所属的API群组及版本
      kind <string>  # 被引用对象的资源类型，多为Pod
      name <string>  # 对象名称
      namespace <string>  # 对象所属的名称究竟
      fieldPath <string>  # 被引用的对象的字段，在未引用整个对象时使用，常用于仅引用
# 指定Pod对象中的单容器，例如spec.containers[1]
      uid <string>     # 对象的标识符；
  notReadyAddresses:  # 处于“未就绪”状态的端点地址对象列表，格式与address相同
  ports:                # 端口对象列表
  - name <string>  # 端口名称；
    port <integer>  # 端口号，必选字段；
    protocol <string>     # 协议类型，仅支持UDP、TCP和SCTP，默认为TCP；
    appProtocol <string>  # 应用层协议；

—

Endpoints Example

将外部MySQL引入到集群内部中来

Ingress

IngressClass Explain

IngressClass 一般用于将一个特定的 IngressClass 标记为集群默认 Ingress 类，以确保新的未指定 ingressClassName 字段的 Ingress 能够分配为这个默认的 IngressClass.
- 将一个 IngressClass 资源的 ingressclass.kubernetes.io/is-default-class 注解设置为 true
还可以定义其相关参数以及作用域；

apiVersion: networking.k8s.io/v1beta1  # API资源群组及版本
kind: IngressClass   # 资源类型标识
metadata:
  name <string>
  namespace <string>
  annotations:
    ingressclass.kubernetes.io/is-default-class <boolean>  # 是否为默认，true表示该IngressClass为默认
spec:
  controller <string>   # 该类别关联的Ingress控制器
  parameters <Object>   # 控制器相关的参数，这些参数由引用的资源定义，可选字段
    apiGroup <string>   # 引用的目标资源所属的API群组
    kind <string>   # 引用的资源类型
    name <string>   # 引用的资源名称

范例：集群作用域

IngressClass 的参数默认是集群范围的

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # 此 IngressClass 的配置定义在一个名为 “external-config-1” 的
    # ClusterIngressParameter（API 组为 k8s.example.net）资源中。
    # 这项定义告诉 Kubernetes 去寻找一个集群作用域的参数资源。
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

范例：名称空间作用域

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # 此 IngressClass 的配置定义在一个名为 “external-config” 的
    # IngressParameter（API 组为 k8s.example.com）资源中，
    # 该资源位于 “external-configuration” 命名空间中。
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

—

Ingress-Nginx 概述

Ingress-Nginx 是一个基于 Nginx 的 Ingress 控制器。

Service

Service 概述

https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/

Service 是 kubernetes 内部的负载均衡，名称空间级别资源；
Pod 在重建后IP地址会发生变化，而使用 Service 来实现对 Pod 的访问就不会受到影响
Service 与其后端 Pod 副本集群之间则是通过 Label Selector 实现关联。
每个 service 都有一个独立的子网；

kube-proxy & Service

kube-proxy 和 Service 的关系：

kube-proxy 通过 k8s-apiserver 监听着 service ，一旦 service 资源发生变化，kube-proxy 就会生成对应的负载调度的调整（添加或删除 iptables 或 ipvs规则），从而保证 service 处于最新状态

Service 代理模式

Userspace

早期方式，性能较差

iptables

iptables代理模式下的ClusterIP，每个Service在每个节点上（由kube-proxy负责生成）都会生成相应的iptables规则

设置为 iptables 代理模式

默认就是 iptables 代理模式

iptables 代理模式工作原理

KUBE-SERVICES

包含所有ClusterIP类型的Service的流量匹配规则，由PREROUTING和OUTPUT两个内置链直接调用；每个Service对象包含两条规则定义，对于所有发往该Service（目标IP为Service_IP且目标端口为Service_Port）的请求报文，前一条用于为那些非源自Pod网络（! -s 10.244.0.0/16）中请求报文借助于KUBE-MARQ-MASK自定义链中的规则打上特有的防火墙标记，后一条负责将所有报文转至专用的以KUBE-SVC为名称前缀的自定义链，后缀是Service信息hash值。

ServiceAccount

ServiceAccount 概述

ServiceAccount 服务账号，简称 sa，名称空间级别资源，因此可以在不同的名称空间中定义同名的用户
ServiceAccount 是 Kubernetes API 所管理的用户
ServiceAccount 用于 Pod 中的应用程序在访问 API Server 时认证使用
- 在 Kubernetes 中，Pod 中的应用程序可以使用 ServiceAccount 身份验证令牌来向 Kubernetes API Server 发出请求并访问资源。
- 当 Pod 中的应用程序需要向 Kubernetes API 发出请求时，它会使用与其关联的 ServiceAccount 的身份验证令牌进行身份验证。Kubernetes API Server 会验证该身份验证令牌是否有效，并检查 ServiceAccount 是否被授予了相应的访问权限。如果验证成功，则应用程序可以访问 Kubernetes API 并执行相应的操作。
- 通常，管理员会将 ServiceAccount 与相应的 RBAC 角色和角色绑定配合使用，以确保 Pod 中的应用程序只能访问其所需的资源。这有助于提高 Kubernetes 集群的安全性，并减少因应用程序的错误或恶意操作而导致的不良后果。
在 Kubernetes 中，每个 Pod 都与一个 ServiceAccount 关联，并且可以使用该 ServiceAccount 的身份验证令牌向 Kubernetes API 发出请求。当 Pod 中的应用程序需要访问自身的信息时，它可以使用 ServiceAccount 的身份验证令牌向 Kubernetes API 查询相关信息，例如 Pod 的 IP 地址、元数据和标签等。