附034.Kubernetes_v1.21.0高可用部署架构二 (7)

Kubernetes的早期版本依靠Heapster来实现完整的性能数据采集和监控功能，Kubernetes从1.8版本开始，性能数据开始以Metrics API的方式提供标准化接口，并且从1.10版本开始将Heapster替换为Metrics Server。在Kubernetes新的监控体系中，Metrics Server用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。
对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成。

开启聚合层

有关聚合层知识参考：https://blog.csdn.net/liukuan73/article/details/81352637
kubeadm方式部署默认已开启。

获取部署文件 [root@master01 ~]# mkdir metrics [root@master01 ~]# cd metrics/ [root@master01 metrics]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml [root@master01 metrics]# vi components.yaml …… apiVersion: apps/v1 kind: Deployment …… spec: replicas: 3 #根据集群规模调整副本数 …… spec: hostNetwork: true containers: - args: - --cert-dir=http://www.likecs.com/tmp - --secure-port=4443 - --kubelet-insecure-tls #追加此args - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname,InternalDNS,ExternalDNS #追加此args - --kubelet-use-node-status-port image: k8s.gcr.io/metrics-server/metrics-server:v0.4.2 imagePullPolicy: IfNotPresent …… 正式部署 [root@master01 metrics]# kubectl apply -f components.yaml [root@master01 metrics]# kubectl -n kube-system get pods -l k8s-app=metrics-server NAME READY STATUS RESTARTS AGE metrics-server-7bc5984686-px9lr 1/1 Running 0 66s metrics-server-7bc5984686-qffb2 1/1 Running 0 66s metrics-server-7bc5984686-t89z5 1/1 Running 0 66s 查看资源监控 [root@master01 ~]# kubectl top nodes [root@master01 ~]# kubectl top pods --all-namespaces

提示：Metrics Server提供的数据也可以供HPA控制器使用，以实现基于CPU使用率或内存使用值的Pod自动扩缩容功能。
部署参考：https://linux48.com/container/2019-11-13-metrics-server.html
有关metrics更多部署参考：
https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/
开启开启API Aggregation参考：
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
API Aggregation介绍参考：
https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/

Nginx ingress部署

通常Service的表现形式为IP:Port，即工作在TCP/IP层。
对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务（RS）或者虚拟服务器（Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。
从Kubernetes 1.1版本开始新增Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。
Kubernetes使用了一个Ingress策略定义和一个具体的Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用。
简单的理解就是：ingress使用DaemonSet或Deployment在相应Node上监听80，然后配合相应规则，因为Nginx外面绑定了宿主机80端口（就像 NodePort），本身又在集群内，那么向后直接转发到相应ServiceIP即可实现相应需求。ingress controller + ingress 规则 ----> services。
同时当Ingress Controller提供的是对外服务，则实际上实现的是边缘路由器的功能。
典型的HTTP层路由的架构：

设置标签 [root@master01 ~]# kubectl label nodes master0{1,2,3} ingress=enable

提示：建议对于非上次业务相关的应用（如Ingress），部署在master节点，也能复用master节点的高可用。

获取资源 [root@master01 ~]# mkdir ingress [root@master01 ~]# cd ingress/ [root@master01 ingress]# wget

提示：ingress官方参考：https://github.com/kubernetes/ingress-nginx
https://kubernetes.github.io/ingress-nginx/deploy/

修改配置

为方便后续管理和排障，对相关Nginx ingress挂载时区，以便于使用主机时间。
同时对ingress做了简单配置，如日志格式等。

[root@master01 ingress]# vi deploy.yaml …… apiVersion: apps/v1 kind: Deployment #kind: DaemonSet …… spec: replicas: 3 …… image: k8s.gcr.io/ingress-nginx/controller:v0.45.0 …… volumeMounts: …… - name: timeconfig mountPath: /etc/localtime readOnly: true …… volumes: …… - name: timeconfig hostPath: path: /etc/localtime nodeSelector: ingress: enable tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule …… apiVersion: v1 kind: ConfigMap metadata: …… data: # 客户端请求头的缓冲区大小 client-header-buffer-size: "512k" # 设置用于读取大型客户端请求标头的最大值number和size缓冲区 large-client-header-buffers: "4 512k" # 读取客户端请求body的缓冲区大小 client-body-buffer-size: "128k" # 代理缓冲区大小 proxy-buffer-size: "256k" # 代理body大小 proxy-body-size: "50m" # 服务器名称哈希大小 server-name-hash-bucket-size: "128" # map哈希大小 map-hash-bucket-size: "128" # SSL加密套件 ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA" # ssl 协议 ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2" # 日志格式 log-format-upstream: '{"time": "$time_iso8601", "remote_addr": "$proxy_protocol_addr", "x-forward-for": "$proxy_add_x_forwarded_for", "request_id": "$req_id","remote_user": "$remote_user", "bytes_sent": $bytes_sent, "request_time": $request_time, "status":$status, "vhost": "$host", "request_proto": "$server_protocol", "path": "$uri", "request_query": "$args", "request_length": $request_length, "duration": $request_time,"method": "$request_method", "http_referrer": "$http_referer", "http_user_agent": "$http_user_agent" }' …… apiVersion: v1 kind: Service …… name: ingress-nginx-controller …… spec: type: NodePort externalTrafficPolicy: Local #追加 ports: - name: http port: 80 protocol: TCP targetPort: http nodePort: 80 - name: https port: 443 protocol: TCP targetPort: https nodePort: 443 …… [root@master01 ingress]# kubectl apply -f deploy.yaml