k8s学习笔记

1.访问顺序

ingress------service--------deployment

2.访问的时候是直接访问的ingress，相当于nginx

配置

比较重点的几个配置

1.kind:Ingress

2.matadata.namespace  命名空间

3.spec.rules.http.paths.path和servicePort以及serviceName

当访问路径是/m-pf-productfactory，会根据serviceName和servicePort找services

如http://127.111.111.1/m-pf-productfactory/service/00000/login

kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: m-pf-productfactory
  namespace: extdev
  selfLink: /apis/extensions/v1beta1/namespaces/extdev/ingresses/m-pf-productfactory
  uid: faf0caef-4690-4964-9c5c-6f4730fde83f
  resourceVersion: '6677866'
  generation: 3
  creationTimestamp: '2020-01-15T09:20:56Z'
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: 'false'
spec:
  rules:
    - http:
        paths:
          - path: /m-pf-productfactory
            backend:
              serviceName: m-pf-productfactory
              servicePort: 12100
status:
  loadBalancer: {}

3.service是连接ingress和pod的纽带

被问到：为什么不直接访问deployment而去访问pod

我的理解：1.deployment产生pod，指定数量可实现负载均衡 2.deployment是一个虚拟的，不能直接访问

首先，service存在的意义

pod会增加会减少会死会重启，每次的节点都会变，但是总不能每次他重启，就去更改ingress的配置吧，那能累死，所以就有我们的service

1.selector.app  service去找pod不是根据ip，而是根据名称，这就解决了ip变化的问题

2.kind:Service

3.ingress转发给service原理

ingress中配置的serviceName转发到service配置的metadata.name

ingress中配置的servicePort转发到service配置的spec.ports.port

4.service找pod

service中配置的targetPort和selector.app

5.namespace命名空间

6.Cluster IP：Service的IP地址，此为虚拟IP地址

kind: Service
apiVersion: v1
metadata:
  name: m-pf-productfactory
  namespace: extdev
  selfLink: /api/v1/namespaces/extdev/services/m-pf-productfactory
  uid: 26ecbe24-f544-47be-900e-9b4948eb62c9
  resourceVersion: '6653126'
  creationTimestamp: '2020-01-08T08:41:09Z'
spec:
  ports:
    - name: m-pf-productfactory-svc
      protocol: TCP
      port: 12100
      targetPort: 12100
  selector:
    app: m-pf-productfactory
  clusterIP: 11.111.11.11   #自动生成的  不是你配的
  type: ClusterIP
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
status:
  loadBalancer: {}

4.pod

1.pod和deployment什么关系?

depolyment可以创建pod,service去访问pod而不是直接访问deployment

2.service找pod

service中配置的selector.app找deployment中对应的spec.template.metadata.labels

service中配置的spec.ports.targetport找deploymnet中对应的开放的端口

# 如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝

3.deployment配置文件比较长，可以一块一块看

3.1kind:Deployment

3.2最外层的metadata信息只是声明自己，并不作为service调用

3.2metadata.namespace命名空间

3.3spec.replicas  一个deployment产生几个pod  这里就一个

3.4spec.template.metadata.lables.app  供service访问使用

kind: Deployment
apiVersion: apps/v1
metadata:
  name: m-pf-productfactory
  namespace: extdev
  selfLink: /apis/apps/v1/namespaces/extdev/deployments/m-pf-productfactory
  uid: d558cab2-1ca6-48ea-a8e1-1d98265a0d96
  resourceVersion: '30605938'
  generation: 365
  creationTimestamp: '2020-01-08T08:41:09Z'
  labels:
    app: m-pf-productfactory
  annotations:
    deployment.kubernetes.io/revision: '362'
spec:
  replicas: 1
  selector:
    matchLabels:
      app: m-pf-productfactory
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: m-pf-productfactory

1.image镜像名称

2.command后边跟一堆东西java -jar什么得，是容器启动之后要执行的命令 

      containers:
        - name: m-pf-productfactory
          image: 'www.test.cn:8080/rdgrp/m-pf-productfactory-release:374'
          command:

1.requests是所需最小资源，不达到这个资源，启动不了

2.limits是最大资源限制，超过这个资源，服务会挂掉 

          resources:
            limits:
              cpu: '2'
              memory: 2500Mi
            requests:
              cpu: '1'
              memory: 1228Mi

1.livenessprode存活探针

2.readinessProbe就绪性探针

          livenessProbe:
            httpGet:
              path: /m-pf-productfactory/actuator/readiness
              port: 8000
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 10
          readinessProbe:
            httpGet:
              path: /m-pf-productfactory/actuator/readiness
              port: 8000
              scheme: HTTP
            initialDelaySeconds: 20
            timeoutSeconds: 1
            periodSeconds: 5
            successThreshold: 1
            failureThreshold: 5

kubelet使用liveness探针知道什么时候重新启动容器,使用readyness探测器来了解容器何时准备开始接受流量

后续1.

如果服务想直接访问服务，可以不通过ingress，直接用servicename+port访问service,前提是同一个命名空间下

比如

 别人的服务部署到线上 访问不到我得服务 报了一个错

The service addresses [m-pf-productfactoryclean:12208,] 
of service [com.wish.biz.pf.productfactoryclean.service.CleanDataService:1.0] 
is not available,or specify url not exist in providers  

我提供给他的端口和servicename都对，报错原因是我service中没有配置端口转发

加上下图配置，问题解决

那个name只是一个name,随便起的，没什么用

后续2

1.就绪探针和存活探针

springboot的actuator监控

在SpringBoot-2.3版本中，actuator新增了两个地址：/actuator/health/liveness和/actuator/health/readiness，前者用作kubernetes的存活探针，后者用作kubernetes的就绪探针；

掌握SpringBoot-2.3的容器探针：基础篇 - 知乎

2.挂载

 3.保密字典

拉取镜像时，把这个作为key，在k8s的secrets中获取用户名密码

      imagePullSecrets:
      - name: 12345

4.副本集

记录历史版本，便于回滚

5. nodes和master

6.git,jenkins,k8s

jenkins去关联git和k8s  git合并触发jenkins构建，jenkins构建成功（镜像上传成功）后触发k8s重启

1.git的webhook配置关联jenkins的地址

2.jenkins配置镜像

注:如果不关联k8s部署，只是作为jar包发布到仓库，就不用配置镜像

7.补缺环境

8.由于服务器资源不够，导致部署到k8s的项目起不来

解决方法：修改resources.requests.cpu和resources.limits.cpu

小于最小资源起不来，大于最大资源会自动重启

可以使用requests来设置各容器需要的最小资源
limits用于限制运行时容器占用的资源，用来限制容器的最大CPU、内存的使用率。
当容器申请内存超过limits时会被终止，并根据重启策略进行重启。

resources:
            limits:
              cpu: 200m
              memory: 2500Mi
            requests:
              cpu: 100m
              memory: 1228Mi

9.线上启动时k8s报拉去不下来镜像

原因：我jenkins的镜像名称配置错了

10.k8s中config map的作用

正常访问是需要通过ingress的，但是如果配置了端口映射

就可以通过k8s的外网Ip和映射出来的端口号，访问线上的service

在本地就可以通过映射出来的12202这个端口访问线上的服务，上边的extdev是命名空间

11.线上，跨namespace如何访问

需要加上namespace

svc.namspece:port

下图：huaian-fat就是另一个命名空间下的服务，本来，同一个命名空间下，用plat-idgeneration:12200就好

12.k8s拉取镜像时，需要配置imagePullSecrets

imagePullSecrets中的值在保密字典中

13.节点选择器nodeSelector

去找key是11-14，value也是11-14的所有机器

这块的node11-14是给服务器打上的标签

14.k8s挂载配置文件

网上前篇一律都是这个，但是可以借鉴

k8s容器挂载配置文件_weixin_30246221的博客-CSDN博客

15.k8s配置达梦独写分离

与7有关，读写分离也是挂载配置文件

15.1服务器上需要上传并配置dm_svc.conf文件，并配置k8s的config maps

15.2达梦连接，由ip改为域名 jdbc:dm://DM_RWC?rwSeparate=1

15.3k8s的部署文件，需要修改

注意volumes和volumeMounts的name必须一致

volumes中添加

        - name: dm-svc-config
          configMap:
            name: dm-svc-config
            defaultMode: 420 #是指要挂载容器内部的文件的权限 （必须是介于0和0777（八进制）之间的数字，包括两者在内）

volumeMounts中添加

            - name: dm-svc-config
              readOnly: true
              mountPath: /etc/dm_svc.conf
              subPath: dm_svc.conf #加上 subPath 强制识别文件

15.4踩坑记录

之前没加subPath,我在pod上执行查看配置文件命令时报这不是一个文件，说明这个时候没挂载上这个文件

加上subPath后，再查看就正常了

16.线上启动失败

16.1我已经看到打印启动成功的日志了，但还是启动失败

原因：探针地址无法访问

正常情况下 curl -i 获取到的响应码是200

但是，我这种错误情况，没有获得200成功响应码

解决办法，现在没有完全解决为什么readiness无法访问问题，curl -I 换成了一个可以访问的url

curl -I http://127.0.0.1:8000/techmidplat-openapi/actuator 

16.2 启动成功之后立马重启

第二天早上发现这个应用已经重启了200多次，观察现象一直是启动成功之后就立马重启

猜测应该是探针时间过短，调大探针超时时间，问题解决

timeoutSeconds从1改为10