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探测器来了解容器何时准备开始接受流量

k8s学习笔记_第1张图片

后续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中没有配置端口转发

加上下图配置,问题解决

k8s学习笔记_第2张图片

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

后续2

1.就绪探针和存活探针

springboot的actuator监控

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

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

k8s学习笔记_第3张图片

2.挂载

k8s学习笔记_第4张图片

 3.保密字典

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

      imagePullSecrets:
      - name: 12345

k8s学习笔记_第5张图片

4.副本集

记录历史版本,便于回滚

k8s学习笔记_第6张图片5. nodes和master

k8s学习笔记_第7张图片

k8s学习笔记_第8张图片

6.git,jenkins,k8s

jenkins去关联git和k8s  git合并触发jenkins构建,jenkins构建成功(镜像上传成功)后触发k8s重启

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

k8s学习笔记_第9张图片

2.jenkins配置镜像

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

k8s学习笔记_第10张图片

k8s学习笔记_第11张图片

k8s学习笔记_第12张图片

7.补缺环境

k8s学习笔记_第13张图片

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

解决方法:修改resources.requests.cpuresources.limits.cpu

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

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

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

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

k8s学习笔记_第14张图片

k8s学习笔记_第15张图片

10.k8s中config map的作用

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

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

k8s学习笔记_第16张图片

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

k8s学习笔记_第17张图片

11.线上,跨namespace如何访问

需要加上namespace

svc.namspece:port

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

k8s学习笔记_第18张图片

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

k8s学习笔记_第19张图片

imagePullSecrets中的值在保密字典中

k8s学习笔记_第20张图片

13.节点选择器nodeSelector

k8s学习笔记_第21张图片

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

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

k8s学习笔记_第22张图片

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上执行查看配置文件命令时报这不是一个文件,说明这个时候没挂载上这个文件

k8s学习笔记_第23张图片

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

k8s学习笔记_第24张图片

16.线上启动失败

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

原因:探针地址无法访问

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

k8s学习笔记_第25张图片

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

k8s学习笔记_第26张图片

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

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

16.2 启动成功之后立马重启

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

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

timeoutSeconds从1改为10

你可能感兴趣的