K8S笔记_ingress的externalname语法

参考链接

(76条消息) 人手一套k8s常用命令集合_北溟溟的博客-CSDN博客

k8s常用命令

1 基本概念

1.1 简介

Kubernetes 是Google开源的容器集群管理系统，基于GO语言，Borg 的开源版本

主要功能包括：

基于容器的应用部署、维护和滚动升级

负载均衡和服务发现

跨机器和跨地区的集群调度

自动伸缩

无状态服务和有状态服务

广泛的 Volume 支持

插件机制保证扩展性

1.2 核心组件

1. 核心组件：

etcd 键值对数据库 保存了整个集群的状态（持久化），推荐在集群中使用ETCDD v3；

api server 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；

controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；

kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；

Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；

kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡，负责写入规则至IPTABLES、IPVS实现服务映射访问

1. 其它插件说明

COREDNS 可以为集群中的SVC创建一个域名IP的对应关系解析

DASHBOARD 给K8S集群提供一个B/S结构访问体系

INGRESS CONTROLLER 官方只能实现四层代理，INGRESS 可以实现七层代理

FEDERATION 提供一个可以跨集群中心多K8S统一管理功能

PROMETHEUS 提供K8S集群的监控能力

ELK 提供K8S集群日志统一分析介入平台

1.3 Pod

1.3.1 概念

Kubernetes 使用 Pod 来管理容器，每个 Pod 可以包含一个或多个紧密关联的容器。

Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是Kubernetes 调度的基本单位。Pod 内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

1.3.2 分类

1. 自主式Pod

1. 控制器管理的Pod

• ReplicationController & ReplicaSet & Deployment

ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且ReplicaSet 支持集合式的selector

虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet ，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持rolling-update 但 Deployment 支持）

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：

• 定义 Deployment 来创建 Pod 和 ReplicaSet

• 滚动升级和回滚应用

• 扩容和缩容

• 暂停和继续 Deployment

Deployment滚动更新的实现，依赖的是Kubernetes中的ReplicaSet

Deployment控制器实际操纵的是ReplicaSet对象，而不是Pod对象

HPA（HorizontalPodAutoScale）
Horizontal Pod Autoscaling 仅适用于 Deployment 和 ReplicaSet ，在 V1 版本中仅支持根据 Pod的 CPU 利用率扩所容，在 v1alpha 版本中，支持根据内存和用户自定义的 metric 扩缩容

• StatefulSet

StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

• 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现

• 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service ）来实现

• 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现

• 有序收缩，有序删除（即从 N-1 到 0）

• DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

使用 DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。*

• 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。

• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter

• Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

Cron Job 管理基于时间的 Job，即：

• 在给定时间点只运行一次

• 周期性地在给定时间点运行

1.4 Service

1.4.1 概念

Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略——通常称为微服务。这一组Pod能够被Service访问到，通常是通过LabelSelector

Service 是对一组提供相同功能的 Pods 的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。

Service 通过标签来选取服务后端，一般配合 Replication Controller 或者 Deployment来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints，由kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。

Service能够提供负载均衡的能力，但是在使用上有以下限制：

• 只提供4层负载均衡能力（通过IP和端口），而没有7层功能（通过主机名或域名），但有时我们可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的

1.4.2 类型

Service在K8s中有以下四种类型

• ClusterIp：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP

• NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过<NodeIP>:NodePort来访问该服务

• LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部负载均衡器，并将请求转发到<NodeIP>:NodePort

• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有kubernetes 1.7或更高版本的kube-dns才支持

apiserver通过kube-proxy监听服务和端点，kube-proxy负责监控到对应的匹配到的pod的信息，将其写入到iptables的规则中去。client想要访问svc时，其实访问的就是iptables规则，被导向后端pod的信息。client访问到节点是通过iptables实现的，iptables规则是通过kube-proxy写入的，kube-proxy会通过pod的标签去判断一个端点的信息是否被写入svc的端点信息中。

实验：

1. ClusterIP

clusterIP主要在每个node节点使用iptables，将发向clusterIP对应端口的数据，转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口

为了实现图上的功能，主要需要以下几个组件的协同工作：

• apiserver用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中

• kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中

• iptables使用NAT等技术将virtualIP的流量转至endpoint中

创建myapp-deploy.yaml文件：

[root@mastermanifests]#vimmyapp-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
    name: myapp-deploy
    namespace: default
spec:
    replicas: 3
    selector:
      matchLabels:
        app:myapp
        release:stabel
    template:
      metadata:
        labels:
            app:myapp
            release:stabel
            env:test
     spec:
        containers:
            -name:myapp
            image:wangyanglinux/myapp:v2
            imagePullPolicy:IfNotPresent
            ports:
                -name:http
                containerPort:80

创建Service信息

[root@master manifests]# vim myapp-service.yaml
apiVersion: v1
kind: Service
metadata:
    name: myapp
    namespace: default
spec:
    type: ClusterIP
    selector:
        app: myapp
        release: stabel
    ports:
        - name: http
        port: 80
        targetPort: 80

1. Headless Service

有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定ClusterIP(spec.clusterIP)的值为“None”来创建Headless Service。这类Service并不会分配Cluster IP，kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。

[root@k8s-master mainfests]# vim myapp-svc-headless.yaml
apiVersion: v1
kind: Service
metadata:
    name: myapp-headless
    namespace: default
spec:
    selector:
        app: myapp
    clusterIP: "None"
    ports:
    - port: 80
      targetPort: 80
[root@k8s-master mainfests]# dig -t A myapp-headless.default.svc.cluster.local.
@10.96.0.10

1. NodePort

nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步到给对应的pod

[root@k8s-master mainfests]# vim myapp-service.yaml
apiVersion: v1
kind: Service
metadata:
    name: myapp
    namespace: default
spec:
    type: NodePort
    selector:
        app: myapp
        clusterIP: stabel
    ports:
    - name: http
      port: 80
      targetPort: 80

查询流程：

iptables -t nat -nvL
KUBE-NODEPORTS

1. LoadBalancer

loadBalancer和nodePort其实是同一种方式。区别在于loadBalancer比nodePort多了一步，就是可以调用cloud provider去创建LB来向节点导流

1. ExternalName

这种类型的Service通过返回CNAME和它的值，可以将服务映射到externalName字段的内容(例如：hub.atguigu.com )。ExternalName Service是Service的特例，它没有selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

kind: Service
apiVersion: v1
metadata:
    name: my-service-1
    namespace: default
spec:
    type: ExternalName
    externalName: hub.atguigu.com

当查询主机my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发

1.4.3 VIP和Service代理

在Kubernetes集群中，每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）的形式，而不是ExternalName的形式。

在Kubernetes v1.0版本，代理完全在userspace。在Kubernetes v1.1版本，新增了iptables代理，但并不是默认的运行模式。从Kubernetes v1.2起，默认就是iptables代理。

在Kubernetes v1.8.0-beta.0中，添加了ipvs代理

在Kubernetes 1.14版本开始默认使用ipvs代理

在Kubernetes v1.0版本，Service是“4层”（TCP/UDP over IP）概念。在Kubernetes v1.1版本，新增了IngressAPI（beta版），用来表示“7层”（HTTP）服务

为何不使用round-robin DNS？（DNS会缓存）

代理模式的分类：

1. userspace代理模式

1. iptables代理模式

1. ipvs代理模式

这种模式，kube-proxy会监视Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与Kubernetes Service对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod

与iptables类似，ipvs于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：

• rr：轮询调度

• lc：最小连接数

• dh：目标哈希

• sh：源哈希

• sed：最短期望延迟

• nq：不排队调度

1.4.4 Ingress

https://www.cnblogs.com/liugp/archive/2022/06/18/16380099.html

概念：

节点：Kubernetes 集群中的服务器；

集群：Kubernetes 管理的一组服务器集合；

边界路由器：为局域网和 Internet 路由数据包的路由器，执行防火墙保护局域网络；

集群网络：遵循 Kubernetes网络模型 实现集群内的通信的具体实现，比如 flannel和 OVS。

服务：Kubernetes 的服务 (Service) 是使用标签选择器标识的一组 pod Service。

除非另有说明，否则服务的虚拟 IP 仅可在集群内部访问。

什么是 Ingress？

通常情况下，service 和 pod 的 IP 仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service 在 Node 上暴露的 NodePort 上，然后再由 kube-proxy 通过边缘路由器 (edge router) 将其转发给相关的 Pod 或者丢弃。

Ingress 可以给 service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 Ingress controller，它监听Ingress 和 service 的变化，并根据规则配置负载均衡并提供访问入口。

ingress 使用开源的反向代理负载均衡器来实现对外暴漏服务，比如 Nginx、Apache、Haproxy等。Nginx Ingress 一般有三个组件组成：

• ingress是kubernetes的一个资源对象，用于编写定义规则。

• 反向代理负载均衡器，通常以Service的Port方式运行，接收并按照ingress定义的规则进行转发，通常为nginx，haproxy，traefik等，本文使用nginx。

• ingress-controller，监听apiserver，获取服务新增，删除等变化，并结合ingress规则动态更新到反向代理负载均衡器上，并重载配置使其生效。

以上三者有机的协调配合起来，就可以完成 Kubernetes 集群服务的暴漏。

2 异常