Kubernetes-service资源

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

实验目的：

配置：

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

---

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/rewrite-target: https://www3.k8s-test.com:30961

spec:

rules:

- host: redirect.k8s-test.com

http:

paths:

- path: /

backend:

serviceName: nginx-svc1

servicePort: 80

24. 深入解析声明式API（一）：API对象的奥秘

K8S存储

Comments NOTHING

取消回复