5.1.Service 介绍
5.1.1.Serice 简介
5.1.1.1 什么是 Service
service 是 k8s 中的一个重要概念, 主要是提供负载均衡和服务自动发现.
Service 是由 kube-proxy 组件, 加上 iptables 来共同实现的.
5.1.1.2.Service 的创建
创建 Service 的方法有两种:
1. 通过 kubectl expose 创建
#kubectl expose deployment nginx --port=88 --type=NodePort --target-port=80 --name=nginx-service
这一步说是将服务暴露出去, 实际上是在服务前面加一个负载均衡, 因为 pod 可能分布在不同的结点上.
-port: 暴露出去的端口
-type=NodePort: 使用结点 + 端口方式访问服务
-target-port: 容器的端口
-name: 创建 service 指定的名称
2. 通过 YAML 文件创建
创建一个名为 hostnames-yaohong 的服务, 将在端口 80 接收请求并将链接路由到具有标签选择器是 App=hostnames 的 pod 的 9376 端口上.
使用 kubectl creat 来创建 serivice
- apiVersion: v1
- kind: Service
- metadata:
- name: hostnames-yaohong
- spec:
- selector:
- App: hostnames
- ports:
- - name: default
- protocol: TCP
- port: 80 // 该服务的可用端口
- targetPort: 9376 // 具有 App=hostnames 标签的 pod 都属于该服务
5.1.1.3. 检测服务
使用如下命令来检查服务:
- $ kubectl get svc
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- kubernetes ClusterIP 10.187.0.1 <none> 443/TCP 18d
5.1.1.4. 在运行的容器中远程执行命令
使用 kubectl exec 命令来远程执行容器中命令
- $ kubectl -n kube-system exec coredns-7b8dbb87dd-pb9hk -- ls /
- bin
- coredns
- dev
- etc
- home
- lib
- media
- mnt
- proc
- root
- run
- sbin
- srv
- sys
- tmp
- usr
- var
双横杠 (--) 代表 kubectl 命令项的结束, 在双横杠后面的内容是指 pod 内部需要执行的命令.
5.2. 连接集群外部的服务
5.2.1. 介绍服务 endpoint
服务并不是和 pod 直接相连的, 介于他们之间的就是 Endpoint 资源.
Endpoint 资源就是暴露一个服务的 IP 地址和端口列表.
通过 service 查看 endpoint 方法如下:
- $ kubectl -n kube-system get svc kube-dns
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- kube-dns ClusterI
- P 10.187.0.2 <none> 53/UDP,53/TCP 19d
- $ kubectl -n kube-system describe svc kube-dns
- Name: kube-dns
- Namespace: kube-system
- Labels: addonmanager.kubernetes.io/mode=Reconcile
- k8s-App=kube-dns
- kubernetes.io/cluster-service=true
- kubernetes.io/name=CoreDNS
- Annotations: kubectl.kubernetes.io/last-applied-configuration:
- {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"prometheus.io/scrape":"true"},"labels":{"addonmanager.kubernetes.io/mode":...
- prometheus.io/scrape: true
- Selector: k8s-App=kube-dns
- Type: ClusterIP
- IP: 10.187.0.2
- Port: dns 53/UDP
- TargetPort: 53/UDP
- Endpoints: 10.186.0.2:53,10.186.0.3:53 // 代表服务 endpoint 的 pod 的 ip 和端口列表
- Port: dns-tcp 53/TCP
- TargetPort: 53/TCP
- Endpoints: 10.186.0.2:53,10.186.0.3:53
- Session Affinity: None
- Events: <none>
直接查看 endpoint 信息方法如下:
- #kubectl -n kube-system get endpoints kube-dns
- NAME ENDPOINTS AGE
- kube-dns 10.186.0.2:53,10.186.0.3:53,10.186.0.2:53 + 1 more... 19d
- #kubectl -n kube-system describe endpoints kube-dns
- Name: kube-dns
- Namespace: kube-system
- Labels: addonmanager.kubernetes.io/mode=Reconcile
- k8s-App=kube-dns
- kubernetes.io/cluster-service=true
- kubernetes.io/name=CoreDNS
- Annotations: <none>
- Subsets:
- Addresses: 10.186.0.2,10.186.0.3
- NotReadyAddresses: <none>
- Ports:
- Name Port Protocol
- ---- ---- --------
- dns 53 UDP
- dns-tcp 53 TCP
- Events: <none>
5.2.2. 手动配置服务的 endpoint
如果创建 pod 时不包含选择器, 则 k8s 将不会创建 endpoint 资源. 这样就需要创建 endpoint 来指的服务的对应的 endpoint 列表.
service 中创建 endpoint 资源, 其中一个作用就是用于 service 知道包含哪些 pod.
5.2.3. 为外部服务创建别名
除了手动配置来访问外部服务外, 还可以使用完全限定域名 (FQDN) 访问外部服务.
- apiVersion: v1
- kind: Service
- metadata:
- name: Service-yaohong
- spec:
- type: ExternalName // 代码的 type 被设置成了 ExternalName
- externalName: someapi.somecompany.com // 实际服务的完全限定域名(FQDN)
- port: - port: 80
服务创建完成后, pod 可以通过 external-service.default.svc.cluster.local 域名 (甚至是 external-service) 连接外部服务.
5.3. 将服务暴露给外部客户端
有 3 种方式在外部访问服务:
1. 将服务的类型设置成 NodePort;
2. 将服务的类型设置成 LoadBalance;
3. 创建一个 Ingress 资源.
5.3.1. 使用 nodeport 类型的服务
NodePort 服务是引导外部流量到你的服务的最原始方式. NodePort, 正如这个名字所示, 在所有节点 (虚拟机) 上开放一个特定端口, 任何发送到该端口的流量都被转发到对应服务.
YAML 文件类似如下:
- apiVersion: v1
- kind: Service
- metadata:
- name: Service-yaohong
- spec:
- type: NodePort // 为 NodePort 设置服务类型
- ports:
- - port: 80
- targetPort: 8080
- nodeport: 30123 // 通过集群节点的 30123 端口可以访问服务
- selector:
- App: yh
这种方法有许多缺点:
1. 每个端口只能是一种服务
2. 端口范围只能是 30000-32767
如果节点 / VM 的 IP 地址发生变化, 你需要能处理这种情况
基于以上原因, 我不建议在生产环境上用这种方式暴露服务. 如果你运行的服务不要求一直可用, 或者对成本比较敏感, 你可以使用这种方法. 这样的应用的最佳例子是 demo 应用, 或者某些临时应用.
5.3.2. 通过 Loadbalance 将服务暴露出来
LoadBalancer 服务是暴露服务到 internet 的标准方式. 在 GKE 上, 这种方式会启动一个 Network Load Balancer[2], 它将给你一个单独的 IP 地址, 转发所有流量到你的服务.
通过如下方法来定义服务使用负载均衡
- apiVersion: v1
- kind: Service
- metadata:
- name: loadBalancer-yaohong
- spec:
- type: LoadBalancer // 该服务从 k8s 集群的基础架构获取负载均衡器
- ports:
- - port: 80
- targetPort: 8080
- selector:
- App: yh
何时使用这种方式?
如果你想要直接暴露服务, 这就是默认方式. 所有通往你指定的端口的流量都会被转发到对应的服务. 它没有过滤条件, 没有路由等. 这意味着你几乎可以发送任何种类的流量到该服务, 像 HTTP,TCP,UDP,websocket,gRPC 或其它任意种类.
这个方式的最大缺点是每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址, 每个用到的 LoadBalancer 都需要付费, 这将是非常昂贵的.
5.4. 通过 Ingress 暴露服务
为什么使用 Ingress, 一个重要的原因是 LoadBalancer 服务都需要创建自己的负载均衡器, 以及独有的公有 Ip 地址, 而 Ingress 只需要一个公网 Ip 就能为许多服务提供访问.
5.4.1. 创建 Ingress 资源
Ingress 事实上不是一种服务类型. 相反, 它处于多个服务的前端, 扮演着 "智能路由" 或者集群入口的角色.
你可以用 Ingress 来做许多不同的事情, 各种不同类型的 Ingress 控制器也有不同的能力.
编写如下 ingress.YAML 文件
- kind: Ingress
- metadata:
- name: ingressyaohong
- spec:
- rules:
- - host: kubia.example.com
- http:
- paths:
- - path: /
- backend:
- serviceName: kubia-nodeport
- servicePort: 80
通过如下命令进行查看 ingress
# kubectl create -f ingress.YAML
5.4.2. 通过 Ingress 访问服务
通过 kubectl get ing 命令进行查看 ingress
- # kubectl get ing
- NAME HOSTS ADDRESS PORTS AGE
- ingressyaohong kubia.example.com 80 2m
了解 Ingress 的工作原理
何时使用这种方式?
Ingress 可能是暴露服务的最强大方式, 但同时也是最复杂的. Ingress 控制器有各种类型, 包括 Google Cloud Load Balancer, Nginx,Contour,Istio, 等等. 它还有各种插件, 比如 cert-manager[5], 它可以为你的服务自动提供 SSL 证书.
如果你想要使用同一个 IP 暴露多个服务, 这些服务都是使用相同的七层协议(典型如 HTTP), 那么 Ingress 就是最有用的. 如果你使用本地的 GCP 集成, 你只需要为一个负载均衡器付费, 且由于 Ingress 是 "智能" 的, 你还可以获取各种开箱即用的特性(比如 SSL, 认证, 路由等等).
5.4.3. 通过相同的 Ingress 暴露多少服务
1. 将不同的服务映射到相同的主机不同的路径
- apiVersion: v1
- kind: Ingress
- metadata:
- name: Ingress-yaohong
- spec:
- rules:
- - host: kubia.example.com
- http:
- paths:
- - path: /yh // 对 kubia.example.com/yh 请求转发至 kubai 服务
- backend:
- serviceName: kubia
- servicePort:80
- - path: /foo // 对 kubia.example.com/foo 请求转发至 bar 服务
- backend:
- serviceName: bar
- servicePort:80
2. 将不同的服务映射到不同的主机上
- apiVersion: v1
- kind: Ingress
- metadata:
- name: Ingress-yaohong
- spec:
- rules:
- - host: yh.example.com
- http:
- paths:
- - path: /// 对 yh.example.com 请求转发至 kubai 服务
- backend:
- serviceName: kubia
- servicePort:80
- - host: bar.example.com
- http:
- paths:
- - path: /// 对 bar.example.com 请求转发至 bar 服务
- backend:
- serviceName: bar
- servicePort:80
5.4.4. 配置 Ingress 处理 TLS 传输
客户端和控制器之间的通信是加密的, 而控制器和后端 pod 之间的通信则不是.
- apiVersion: v1
- kind: Ingress
- metadata:
- name: Ingress-yaohong
- spec:
- tls: // 在这个属性中包含所有的 TLS 配置
- - hosts:
- - yh.example.com // 将接收来自 yh.example.com 的 TLS 连接
- serviceName: tls-secret // 从 tls-secret 中获得之前创立的私钥和证书
- rules:
- - host: yh.example.com
- http:
- paths:
- - path: /// 对 yh.example.com 请求转发至 kubai 服务
- backend:
- serviceName: kubia
- servicePort:80
5.5.pod 就绪后发出信号
5.5.1. 介绍就绪探针
就绪探针有三种类型:
1.Exec 探针, 执行进程的地方. 容器的状态由进程的退出状态代码确定.
2.HTTP GET 探针, 向容器发送 HTTP GET 请求, 通过响应 http 状态码判断容器是否准备好.
3.TCP socket 探针, 它打开一个 TCP 连接到容器的指定端口, 如果连接建立, 则认为容器已经准备就绪.
启动容器时, k8s 设置了一个等待时间, 等待时间后才会执行一次准备就绪检查. 之后就会周期性的进行调用探针, 并根据就绪探针的结果采取行动.
如果某个 pod 未就绪成功, 则会从该服务中删除该 pod, 如果 pod 再次就绪成功, 则从新添加 pod.
与存活探针区别:
就绪探针如果容器未准备就绪, 则不会终止或者重启启动.
存活探针通过杀死异常容器, 并用新的正常的容器来替代他保证 pod 正常工作.
就绪探针只有准备好处理请求 pod 才会接收他的请求.
重要性;
确保客户端只与正常的 pod 进行交互, 并且永远不会知道系统存在问题.
5.5.2. 向 pod 添加就绪探针
添加的 YAML 文件如下
- apiVersion: v1
- kind: deployment
- ...
- spec:
- ...
- port:
- containers:
- - name: kubia-yh
- imgress: luksa/kubia
- readinessProbe:
- failureThreshold: 2
- httpGet:
- path: /ping
- port: 80
- scheme: HTTP
- initialDelaySeconds: 30
- periodSeconds: 5
- successThreshold: 1
- timeoutSeconds: 3
相关参数解释如下:
initialDelaySeconds: 容器启动和探针启动之间的秒数.
periodSeconds: 检查的频率(以秒为单位). 默认为 10 秒. 最小值为 1.
timeoutSeconds: 检查超时的秒数. 默认为 1 秒. 最小值为 1.
successThreshold: 失败后检查成功的最小连续成功次数. 默认为 1. 活跃度必须为 1. 最小值为 1.
failureThreshold: 当 Pod 成功启动且检查失败时, Kubernetes 将在放弃之前尝试 failureThreshold 次. 放弃生存检查意味着重新启动 Pod. 而放弃就绪检查, Pod 将被标记为未就绪. 默认为 3. 最小值为 1.
HTTP 探针在 httpGet 上的配置项:
host: 主机名, 默认为 pod 的 IP.
scheme: 用于连接主机的方案(HTTP 或 HTTPS). 默认为 HTTP.
path: 探针的路径.
httpHeaders: 在 HTTP 请求中设置的自定义标头. HTTP 允许重复的请求头.
port: 端口的名称或编号. 数字必须在 1 到 65535 的范围内
模拟就绪探针
- # kubectl exec <pod_name> -- curl http://10.187.0.139:80/ping
- % Total % Received % Xferd Average Speed Time Time Time Current
- Dload Upload Total Spent Left Speed
- 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
5.6. 使用 headless 服务发现独立的 pod
5.6.1. 创建 headless 服务
Headless Service 也是一种 Service, 但不同的是会定义 spec:clusterIP: None, 也就是不需要 Cluster IP 的 Service.
顾名思义, Headless Service 就是没头的 Service. 有什么使用场景呢?
第一种: 自主选择权, 有时候 client 想自己来决定使用哪个 Real Server, 可以通过查询 DNS 来获取 Real Server 的信息.
第二种: Headless Services 还有一个用处(PS: 也就是我们需要的那个特性).Headless Service 的对应的每一个 Endpoints, 即每一个 Pod, 都会有对应的 DNS 域名; 这样 Pod 之间就可以互相访问.
来源: https://www.cnblogs.com/yaohong/p/11478749.html