K8s基础3——应用部署流程、服务编排、集群资源利用率、日志管理

一、应用部署流程

部署流程：

1. 编写dockerfile，制作镜像。
2. 使用控制器部署pod，部署时需要指定制作的镜像。常见控制器有deployment、statefulset、daemonset。
3. 把需要访问交互的应用端口暴露出来，方便数据交互。暴露方式有service、ingress。
4. 暴露出来后，客户端就可以正常访问运维了。
   

基础资源概念：

• Pod：K8s最小部署单元，一组容器的集合。
• Deployment：最常见的控制器，用于更高级别部署和管理Pod。
• Service：为一组Pod提供负载均衡，对外提供统一访问入口。
• Label ：标签，附加到某个资源上，用于关联对象、查询和筛选。
• Namespaces ：命名空间，将对象逻辑上隔离，也利于权限控制，默认有四个。
  • default：默认命名空间。
  • kube-system：K8s系统方面的命名空间。
  • kube-public：公开的命名空间，谁都可以访问。
  • kube-node-lease：K8s内部命名空间。

资源关系图：

二、服务编排

2.1 YAML文件格式说明

• K8s是一个容器编排引擎，使用YAML文件编排要部署应用，因此在学习之前，应先了解YAML语法格式：
  • 缩进表示层级关系。
  • 不支持制表符“tab”缩进，使用空格缩进。
  • 通常开头缩进 2 个空格。
  • 字符后缩进 1 个空格，如冒号、逗号等。
  • “—” 表示YAML格式，一个文件的开始。
  • “#”注释。

2.2 部署应用

2.2.1 命令部署

1.创建一个名为web1的deployment，使用镜像nginx。

[root@k8s-master ~]# kubectl  create deployment web1 --image=nginx
deployment.apps/web created

2.查看是否创建成功。

3.给名为web1的deployment创建一个名为text的service，暴露pod内部应用，应用端口为80，svc端口为80，暴露端口为31697。

[root@k8s-master ~]# kubectl  expose deploy web1 --name=text --port=80 --target-port=80 --type=NodePort

4.集群任意节点IP:31697，访问web页面。

2.2.2 yaml文件部署

• 命令部署虽然繁杂，但初始学习可以很好的运用参数。等熟练后就可以使用yaml文件部署，操作简单。
• 相关命令：
  • 部署：kubectl apply -f xxx.yaml
  • 卸载：kubectl delete -f xxx.yaml

2.2.2.1 编写deployment.yaml文件

1.编辑一个yaml文件，K8s官网deployment.yaml文件模板。

[root@k8s-master bck]# cat qingjun1.yaml 
apiVersion: apps/v1   ## API版本
kind: Deployment      ##资源类型
metadata:             ##资源元数据，包括名称、所在命名空间。
  name: qingjun1    ## 控制器名称。
spec:                 ## 资源规格，包括副本数量、标签选择器。
  replicas: 3
  selector:
    matchLabels:          ##标签选择器，自定义键值对，与metadata.labels保持一致。
      app: demo2 
  template:           ## Pod模板内容，包括Pod元数据、规格、容器配置。
    metadata:         ##pod元数据。
      labels:
        app: demo2
    spec:                   ##pod规格，在下面可以定义服务应用。
      containers:               ##容器规格。
      - name: web     ## Pod名称。
        image: nginx  ##镜像地址。

2.导入yaml文件创建deployment。

[root@k8s-master bck]# kubectl apply -f qingjun1.yaml

3.查看创建结果。

2.2.2.2 编写service.yaml文件

1.编辑一个yaml文件，K8s官方service.yaml文件模板。

[root@k8s-master bck]# cat baimu.yaml 
apiVersion: v1
kind: Service       ##资源类型
metadata:           ##资源元数据，包括资源名称、所在命名空间。
  name: java-demo2    ##资源名称。
spec:               ##资源规格，包括标签选择器。
  selector:         ##标签选择器，与需要暴露关联的deployment中的标签保持一致。
    app: demo2
  ports:
    - protocol: TCP    ##使用协议。
      port: 80           ##svc端口，通过clusterip访问使用，默认80。
      targetPort: 8080     ##容器内运行服务端口
  type: NodePort      ##端口类型，这个类型代表将应用暴露到外面，浏览器能访问。

2.导入yaml文件，查看service。

[root@k8s-master bck]# kubectl apply -f baimu.yaml 
[root@k8s-master bck]# kubectl get service

3.访问web页面。

2.2.2.3 两个yaml文件混用

1.创建一个命名空间test。

[root@k8s-master bck]# kubectl create ns test
namespace/test created

2.创建2个yaml文件，每个yaml里有2段创建资源的内容，中间用“- - -”分开。

[root@k8s-master bck]# cat web1.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web1
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web1
  template:
    metadata:
      labels:
        app: web1
    spec:
      containers:
      - name: web
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: web1
  namespace: test
spec:
  selector:
    app: web1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort



[root@k8s-master bck]# cat web2.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web2
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web2
  template:
    metadata:
      labels:
        app: web2
    spec:
      containers:
      - name: web
        image: httpd
---
apiVersion: v1
kind: Service
metadata:
  name: web2
  namespace: test
spec:
  selector:
    app: web2
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

3.导入两个yaml文件，创建deployment和service。

[root@k8s-master bck]# kubectl apply -f web1.yaml -f web2.yaml 

4.查看结果。

[root@k8s-master bck]# kubectl get pod -n test
[root@k8s-master bck]# kubectl get service -n test

5.访问web1是nginx，访问web2是apache。

2.2.2.4 测试——service和deployment的标签不一致导致访问网页混乱

1.现在蒋web2.yaml文件中的service标签改成web1。

2.重新导入web2.yaml文件，访问网页是Nginx的页面。

[root@k8s-master bck]# kubectl apply -f web2.yaml 
[root@k8s-master bck]# kubectl get service -n test

3.得出结论，service转发是根据deployment的标签来识别的，这种情况是不应该出现的。

4.此时可以查看service转发pod的IP信息。

[root@k8s-master bck]# kubectl get endpoints -n test

5.所以我们常常会给deploytment定义两个标签，与service标签需要一致。

6.卸载服务。

2.2.3 自定义yaml文件

2.2.3.1 create命令生成

命令示范：

• kubectl create deployment nginx --image=nginx:1.16 -o yaml --dry-run=client > my-deploy.yaml

1.先尝试运行，–dry-run参数是尝试运行不实际创建应用资源对象，选择项有client（客户端）、service（API），replicas参数指定创建副本数量。

[root@k8s-master ~]# kubectl  create deployment java-demo --image=nginx --replicas=3 --dry-run=client

2.输出yaml文件内容。

[root@k8s-master ~]# kubectl  create deployment java-demo --image=nginx --replicas=3 --dry-run=client -o yaml

3.导出yaml文件。

[root@k8s-master ~]# kubectl  create deployment java-demo --image=nginx --replicas=3 --dry-run=client -o yaml > deployment.yaml

4.此时可以适当修改导出来的yaml文件内容，因为导出来的内容是给API提交时的内容，有些参数我们用不上。

[root@k8s-master ~]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null     ##时间戳字段，k8s官方维护的，不属于用户定义，删不删出都不影响容器相关操作。这里就可以先删除。
  labels:
    app: java-demo    ##deployment的标签，用于过滤，与service也要保持一样，四点一线，不常用。
  name: java-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: java-demo
  strategy: {}      
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: java-demo
    spec:
      containers:
      - image: lizhenliang/java-demo
        name: java-demo
        resources: {}
status: {}

2.2.3.2 get命令导出

命令示范：

• kubectl get deployment nginx -o yaml > my-deploy.yaml
• 常常用在将已创建的资源yaml文件导出来，方便调试运维。

1.查看已创建的deployment有哪些。

2.导出deployment的yaml文件。

[root@k8s-master ~]# kubectl get deploy web1  -o yaml > web1.yaml

3.查看导出的yaml文件。这里的内容是从k8s里面导出来的，k8s创建资源时会添加很多字段，所以比create创建出来的yaml文件字段多一些。

4.删除不常用的字段，修改后内容如下。

2.2.3.3 查看yaml文件字段

• 当我们在编写yaml时，若是忘记一些字段是可以通过命令来查看的，这个命令非常常用。

命令示范：

• kubectl explain pods.spec.containers
• kubectl explain deployment

1.查看书写格式。

2.查看第一级别。



3.查看spec第一级别。

4.查看第四级别。

[root@k8s-master bck]# kubectl explain deployment.spec.template.spec.containers

三、集群资源利用率

Metrics Server插件概念：

• 是一个集群范围的资源使用情况的数据聚合器，作为一个应用部署在集群中。
• Metric server从每个节点上Kubelet API收集指标，通过K8s聚合器注册在Master APIServer中。为集群提供Node、Pods资源利用率指标。
• 项目地址

工作原理：

1. 使用kubectl top 命令查看资源使用率时，会给apiserver发送请求。
2. metric-server是作为pod部署的，此时apiserver向metric-server发送请求查看它收集各个节点上的资源利用率信息。
3. metric-server作为聚合器通过https方式与各个节点上的kubelet对接，将各节点上的容器使用信息收集过来。
4. kubelet代码里内涵了cadvisor插件，此插件是专门收集容器指标的。

原理图：

官方：

Metrics Server版本	K8s版本
0.6.x	1.19+
0.5.x	*1.8+
0.4.x	*1.8+
0.3.x	1.8-1.21

• 其他版本：
  

3.1 安装插件

1.根据K8s版本下载对应的yaml文件。

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

2.增加kubelet-insecure-tls参数，这个参数作用是告诉metrics-server不验证kubelet提供的https证书。当然也可以使用携带ca证书来访问，但是要挂载比较麻烦。

3.导入查看，如果状态True并能返回数据说明Metrics Server服务工作正常。

 kubectl  apply -f metrics-server.yaml 
 kubectl get apiservices |grep metrics
 kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes

3.2 命令使用

1.查看所有节点cpu使用情况。

2.查看pod的内存使用情况。

四、查看集群资源

1.查看master组件状态。

2.查看节点运行状态。

3.查看资源的详情，此命令在排错时经常用到。

kubectl describe <资源类型> <资源名称>

4.查看资源创建时的yaml文件内容。

kubectl get <资源类型> <资源名称>  -o yaml

5.查看资源状态、IP等详情。

kubectl get <资源类型> <资源名称>  -o wide

6.查看资源标签。

五、日志管理

工作中需要用到哪些日志？

• 组件日志，比如kubelet、apiserver等等。
• 应用服务日志。

日志类型：

1. 标准输出，比如kubelet log 或docker log查看就是将日志输出在屏幕上实时查看。
2. 日志文件，直接查看日志文件里记录的日志。

1.查看kubelet组件日志。所有组件除了kubelet是systemd守护进程管理的组件，其他组件都是pod部署。

[root@k8s-node2 ~]# journalctl -u  kubelet  -f

2.查看其他组件日志。

[root@k8s-node2 ~]# kubectl  logs [pod名称] -n [pod所在命名空间]

3.系统日志，有的组件可以和系统进行交互，有些信息也可以在系统日志中查看。

4.查看标准输出到宿主机的日志文件。

日志管理流程：

1. 使用kubectl logs查看日志时，会给apiserver发送请求，apiserver再给对应节点上的kubelet发送请求日志。
2. 目标节点上的kubelet给docker发送请求，尝试调取docker管理的日志文件。
3. 最后将docker管理的日志我呢见内容标准输到屏幕。

/var/lib/docker/containers/<container-id>/<container-id>-json.log

5.查看容器内日志文件。