wordpress和网盘结合优化器

ingress是一个API资源。

其核心作用是nginx网页服务器。

当客户端访问服务器不同的url时,

用不同的location提供服务。

在k8s之外，nginx的配置一般如下：

http {server {listen       80;server_name  localhost;location / {root   html;             # 网页文件根目录index  index.html index.htm;    #默认首页
#设置默认首页为index.html，当用户在浏览器地址栏中只写域名或IP，不说访问什么页面时,服务器会把默认首页index.html返回给用户}location ~ \.php$ {          # "~"匹配正则表达式，# 当用户访问以.php结尾的网页文件时，服务器按照此模块的定义，提供动态网页服务root           html;                 fastcgi_pass   127.0.0.1:9000;fastcgi_index  index.php;include        fastcgi.conf;}}

在k8s平台，ingress调用nginx的服务，来实现不同的url对应不同的location.

用命令行创建ingress资源文件模版时，需要指定两个参数，

一个是--class=

另一个是--rule=

--class是控制器的类，表明ingress要调用哪个控制器的类作为ingress资源的控制器，

可选nginx和haproxy，一般用nginx

--rule是控制器提供服务的规则，

相当于平常写的location，

在k8s，用命令行创建ingress资源文件的模版时，

一般用--rule="/path=svc:port"来实现"location"的功能。

比如--rule="/hello=hello:3579"

当用户访问/hello路径时，ingress提供名为"hello"的服务，hello服务使3579端口

资源文件如下：

 

spec:ingressClassName: nginxrules:- http:paths:- pathType: Prefixpath: /hellobackend:service:name: helloport:number: 3579

path对应backend:

backend是service，也就是服务

服务名为hello，端口号为3579

定义一个服务名为hello，端口号为3579的后端服务。ingress就能连接到这个服务了。

资源文件如下，是一个nodeport类型的服务（service）:

---
kind: Service
apiVersion: v1
metadata:name: hello
spec:type: NodePortselector:app: websiteports:- name: webprotocol: TCPport: 3579targetPort: http

nodeport是个端口转发类型的服务，

当服务请求到达一个计算节点时，

这个服务将被转发到一个后端端口，

图中的例子，后端端口是http.

而这个http实际上，

就是deployment管理的pod中的容器，所监听的端口名。

在deployment的资源文件中，

定义了一组以http为监听端口名的pod

资源文件如下：

---
kind: Deployment          
apiVersion: apps/v1       
metadata:                 name: deployabc          
spec:                     replicas: 3             selector:               matchLabels:          app: deploy-web     # deployment通过这个标签来确定哪个Pod由它来管理template:               # 定义用来创建 Pod 的模板,以下为 Pod 定义metadata:labels:app: deploy-webspec:containers:- name: apacheimage: myos:httpd       ports:       - name: http            # pod中，容器监听的端口名protocol: TCP         # pod中，容器监听的端口的协议containerPort: 80     # pod中，容器监听的端口号

那么服务请求就会到达pod中的容器。

其实步骤也可以概括为，

客户端---> ingress---> service---->depolyment

因为deployment的具体运作，前面的步骤是可以不用关心的。

deployment定义好其管理的pod的模版的详细情况，包括pod中的容器的信息。

根据这个pod的模版，deployment就可以实时的调整pod的数量

按照需求，来进行弹性管理。

来提供一个自动化管理的pod的集群。