Kubernetes-service资源

1,404次阅读

没有评论

Service 概念

K8S 的 service 定义了一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 – 通常称为微服务。

这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector

Service 能够提供负载均衡的能力，但是在使用上有限制：
只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

service 的类型

ClusterIP：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP
NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 <NodeIP>：NodePort 来访问该

服务

LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到 <NodeIP>:NodePort
ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建

代理模式分类

1、userspace 代理模式

2、iptables 代理模式

3、ipvs 代理模式

这种模式，kube-proxy 会监视 K8S 的 Service 对象和 Endpoints, 调用 netlink 接口以相应地创建 IPVS 规则并定期与 K8S

service 对象同步 IPVS 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod

与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。

这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多

选项，例：

Rr：轮询
Lc：最小连接数
Dh：目标哈希
Sh：源哈希
Sed：最短期望延迟
nq：不排队调度

实验：

[root@k8s-master01 service]# cat server.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stable
  template:
    metadata:
      labels:
        app: myapp
        release: stable
        env: test
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1
        imagePullPolicy: IfNotPresent
[root@k8s-master01 service]# cat service.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  ports:
  - port: 80
    name: http
    targetPort: 80
  selector:
    app: myapp
    release: stable
  type: ClusterIP

Headless Service:

有时不需要或不想要负载均衡，以及单独的 ClusterIP, 可以通过指定 ClusterIP(spec.clusterip) 的值为 ”None” 来创建 Headless Service。

这类 Service 并不会分配 Cluster IP，Kube-proxy 不会处理他们，而且平台也不会它们进行负载均衡和路由

[root@k8s-master01 service]# cat headless-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
  - port: 80
    targetPort: 80

kubectl get pod -n kube-system -o wide

dig -t A myapp-headless.default.svc.cluster.local. @10.244.0.9

解析出来分配的 IP 依然是 Pod 的

kubectl get pod -o wide

NodePort

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

[root@k8s-master01 service]# cat nodeport-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: NodePort
  selector:
    app: myapp
    release: stable
  ports:
  - name: http
    port: 80
    targetPort: 80

LoadBalancer

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

ExternalName

这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 ExternalName 字段的内容（例：test.k8s.com）。ExternalName

Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

---
apiVersion: v1
kind: Service
metadata:
  name: my-service-1
spec:
  type: ExternalName
  externalName: k8s.test.com

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

而且不会进行代理或转发

Ingress 相关

ingress-controller 的安装

国内安装 ingress-controller 拉去不了镜像

方法 1：有国外服务器，在国外服务器上下载，下载好后将镜像导出来，打入 node 节点里面

方法 2：在 dockerhub 上搜索看看是否有别人同步的镜像，在服务器上 pull 下来后重新打 tag

$docker pull liangjw/kube-webhook-certgen:v1.0
$docker pull willdockerhub/ingress-nginx-controller:v1.0.0

$docker tag willdockerhub/ingress-nginx-controller:v1.0.0 k8s.gcr.io/ingress-nginx/controller:v1.0.0
$docker tag liangjw/kube-webhook-certgen:v1.0 k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0
需要注意的是：1.node 节点需要这镜像, 所以可以通过镜像导入来实现
     下载节点执行命令
$docker save ef43679c2cae -o /root/ingress-nginx-controller_v1.tar
$docker save 17e55ec30f20 -o /root/ingress-nginx-kube-webhook-certgen_v1.tar
      node 节点执行命令
$docker tag ef43679c2cae k8s.gcr.io/ingress-nginx/controller:v1.0.0
$docker tag 17e55ec30f20 k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0

完成后运行命令：

[root@k8s-master01 ~]# kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-f9bqh        0/1     Completed   0          22m
ingress-nginx-admission-patch-nrxft         0/1     Completed   0          22m
ingress-nginx-controller-7fc4b4c548-mqgzz   1/1     Running     0          22m

实验：

http 访问

配置：

deployment1.yaml

—

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 2

selector:

matchLabels:

template:

metadata:

labels:

spec:

containers:

– name: nginx1

image: wangyanglinux/myapp:v1

imagePullPolicy: IfNotPresent

ports:

– containerPort: 80

—

apiVersion: v1

kind: Service

metadata:

spec:

ports:

– port: 80

targetPort: 80

protocol: TCP

selector:

deployment2.yaml

—

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 2

selector:

matchLabels:

template:

metadata:

labels:

spec:

containers:

– name: nginx2

image: wangyanglinux/myapp:v2

imagePullPolicy: IfNotPresent

ports:

– containerPort: 80

—

apiVersion: v1

kind: Service

metadata:

spec:

ports:

– port: 80

targetPort: 80

protocol: TCP

selector:

上面为 DM 和 SVC 的配置

下面为 ingress 的配置：

[root@k8s-master01 ingress]# cat ingressrule.yaml

—

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

spec:

rules:

– host: www1.k8s-test.com

http:

paths:

– path: /

backend:

serviceName: nginx-svc1

servicePort: 80

—

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

spec:

rules:

– host: www2.k8s-test.com

http:

paths:

– path: /

backend:

serviceName: nginx-svc2

servicePort: 80

实现 nginx（ingress）根据不同资源走不同 SVC 访问

HTTPS 访问

1、创建证书，以及 cert 存储方式

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj “/cn=nginxsvc/O=nginxsvc”

kubectl create secret tls tls-secret –key tls.key –cert tls.crt

2、Deployment、Service、Ingree yaml 文件

[root@k8s-master01 https]# cat deployment1.yaml

—

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 2

selector:

matchLabels:

template:

metadata:

labels:

spec:

containers:

– name: nginx3

image: wangyanglinux/myapp:v3

imagePullPolicy: IfNotPresent

ports:

– containerPort: 80

—

apiVersion: v1

kind: Service

metadata:

spec:

ports:

– port: 80

targetPort: 80

protocol: TCP

selector:

[root@k8s-master01 https]# cat https.yaml

—

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

spec:

tls:

– hosts:

– www3.k8s-test.com

secretName: tls-secret

rules:

– host: www3.k8s-test.com

http:

paths:

– path: /

backend:

serviceName: nginx-svc3

servicePort: 80

创建好后，使用 kubectl get svc -n ingresss-nginx 命令获取 443 对应的端口

443:30961/TCP

nginx 进行 BasicAuth

yum install -y httpd

htpasswd -c auth foo

kubectl create secret generic basic-auth –from-file=auth

[root@k8s-master01 basic-auth]# cat ingress-auth.yaml

—

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/auth-type: basic

nginx.ingress.kubernetes.io/auth-secret: basic-auth

nginx.ingress.kubernetes.io/auth-realm: ‘Authentication Required – foo’

spec:

rules:

– host: auth.k8s-test.com

http:

paths:

– path: /

backend:

serviceName: nginx-svc1

servicePort: 80

Nginx 进行重写

Name	Description	Values
nginx.ingress.kubernetes.io/rewrite-target	必须将流量重定向到的目标 URI	string
nginx.ingress.kubernetes.io/ssl-redirect	指示位置部分是否仅可访问 SSL（Ingress 包含证书时默认为 True）	bool
nginx.ingress.kubernetes.io/force-ssl-redirect	即使未启用 TLS，也强制将重定向到 HTTPS	bool
nginx.ingress.kubernetes.io/app-root	定义如果在“/”上下文中，控制器必须重定向的应用程序根	string
nginx.ingress.kubernetes.io/use-regex	指示在 Ingress 上定义的路径是否使用正则表达式	bool