使用k8s部署springcloud解决三大问题

1.正式环境使用的话启动时需要指定使用正式的配置文件,这个要咋处理?

解决办法

文章地址:https://www.cnblogs.com/sanduzxcvbnm/p/13262411.html

分析步骤

Dockerfile文件内容如下:

# tag:0.3
FROM idocker.io/jre:1.8.251
VOLUME /tmp
ADD target/hkd-gateway-1.0.jar hkd-gateway-1.0.jar
RUN sh -c 'touch /hkd-gateway-1.0.jar'
ENV JAVA_OPTS=""
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /hkd-gateway-1.0.jar" ]

可以在启动容器的时候把要使用的配置文件给传递给JAVA_OPTS,这样就能解决启动时采用哪个配置文件的问题了

spring.profiles.active=dev|test|prod

原shell启动脚本内容:

#!/bin/bash
java -jar -Xms256m -Xmx256m -XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=9 -XX:+UseConcMarkSweepGC \
 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCDateStamps -XX:+CMSClassUnloadingEnabled -XX:SoftRefLRUPolicyMSPerMB=0 \
 -XX:+PrintGCDetails  -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow \
 -Xloggc:/opt/hkd-cloud/hkd-gateway/logs/heap_trace.txt -XX:HeapDumpPath=/opt/hkd-cloud/hkd-gateway/logs/HeapDumpOnOutOfMemoryError/ /opt/hkd-cloud/hkd-gateway/hkd-gateway-1.0.jar  \
 --spring.profiles.active=dev >> /opt/hkd-cloud/hkd-gateway/logs/hkd-gateway.out 2>&1

本地测试环境使用


正式环境使用


可以把这个配置给写入到ConfigMap 中,然后引用这个就可以了

shell脚本中附加的运行参数处理:


2.日志现在是直接查看的,没有存储到文件中,以后查看日志要咋处理?

解决办法

文章地址:https://www.cnblogs.com/sanduzxcvbnm/p/13259957.html
注:文章中使用logstash了,可以扩展使用redis使用

分析步骤

进一步延申一下问题,容器运行在pod中,容器中的程序日志是输出到pod的控制台中的。所以可以换种说法,如何收集pod的控制台日志?

通过咨询了解到,pod的控制台日志是默认存放在宿主机上,也就是存放在宿主机中的/var/log/pods目录下,这就好办多了,直接使用filebeat读取整个目录下的所有子目录以及日志文件等,具体看下图
当删除该pod或者pod数调整为0的时候,对应的目录和日志文件也就自动没有了

查看上图可以知道。每创建一个新pod,就会在该目录下新建一个文件夹,一个pod有多个副本,则每个副本也都会创建一个文件夹,每个文件夹下是一个以容器名称命名的子文件夹,在这个子文件夹有一个以log结尾的链接文件,实际指向docker中的路径/var/lib/docker/containers

参考文章:k8s 容器控制台日志收集

优点: 如果业务里面把日志全部往控制台输出,对于日志管理是非常的方便的。当删除容器了,日志文件也就没有了,所有不需要额外再写脚本全定时管理日志
缺点: 如果业务中有多种日志需要收集,当然也就可以通过logstash来做,只不过比较麻烦。还需要业务协调

重要:再次参考文章:https://www.cnblogs.com/sanduzxcvbnm/p/13259957.html

这里采用单独的filebeat来收集日志,传输给redis,logstash从redis中拉取数据,在logstash中根据目录名称创建es索引

filebeat配置文件

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/pods/*/*/*.log # paths中的正则会匹配k8s中所有的pod控制台日志
  symlinks: true # 日志文件是软连接形式到docker目录中去的 所以这个开关需要开启

  #json.overwrite_keys: true # #对于同名的key,覆盖原有key值
  #json.add_error_key: true # #将解析错误的消息记录储存在error.message字段中
  #json.keys_under_root: true # #keys_under_root可以让字段位于根节点,默认为false
  #json.message_key: log # #message_key是用来合并多行json日志使用的,如果配置该项还需要配置multiline的设置
  #tail_files: true # 如果设置为true,Filebeat从文件尾开始监控文件新增内容,把新增的每一行文件作为一个事件依次发送,而不是从文件开始处重新发送所有内容  

  #multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
  #multiline.negate: true
  #multiline.match: after
  #multiline.timeout: 10s
 
output.redis:
  hosts: ["192.168.75.21:6379"]
  key: pods_log
  db: 0
  timeout: 5

logstash

使用logstash从redis中拉取数据,处理收集的文件的目录 根据目录名字输出到不同的索引

input { 
  redis {
    host => "192.168.75.21"
    port => 6379
    data_type => "list"
    key => "pods_log"
    db => 0
  }
}

output {

    #stdout { 
    #   codec => rubydebug  
    #}
  
    elasticsearch {
        hosts => ["192.168.75.21:9200"]
        index => "%{[container][id]}-%{+yyyy.MM.dd}"
        user => "elastic"
        password => "IjGj8QwWYeXY7rVoLLQ6"
    }
}

第二天再次启动k8s主机后,这个pod也随之启动了,相对应的日志文件新生成一份。
若是pod一直运行下去,是不是日志文件始终就只有一个?有待进一步验证

3.发布更新的话需要先把服务从注册中心给down下来,然后才能更新模块,这个要咋处理?

解决办法

文章地址:https://www.cnblogs.com/sanduzxcvbnm/p/13268486.html
注:直接看文章最后的内容

分析步骤

使用k8s的postStart和preStop功能,pod的生命周期管理

  • postStart 容器启动时,Kubernetes 立刻发送 postStart 事件,但不确保对应的 handler 是否能在容器的 EntryPoint 之前执行
  • preStop 容器停止前,Kubernetes 发送 preStop 事件

参考之前的相关功能:

curl -v -X PUT http://localhost:8761/eureka/apps/HKD-GATEWAY/hkd-cluster1:hkd-gateway:5000/status?value=DOWN
curl -v -X PUT http://localhost:8761/eureka/apps/HKD-GATEWAY/hkd-cluster1:hkd-gateway:5000/status?value=UP

需要在容器中使用到curl命令,但是tag:0.3镜像中并不包含此命令,所以重构了一个含有curl命令的docker基础镜像,参考文章:https://www.cnblogs.com/sanduzxcvbnm/p/13220054.html
这里以config模块为例

结合现有的信息,改造使用的curl命令等,结果如下:

curl -v -X PUT http://cloud-eureka-0.cloud-eureka.hkd.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888/status?value=DOWN
curl -v -X PUT http://cloud-eureka-0.cloud-eureka.hkd.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888/status?value=UP

说明:

修改config模块的Dockerfile文件,具体如下:

# tag:0.3
#FROM idocker.io/jre:1.8.251
#VOLUME /tmp
#ADD target/hkd-config-1.0.jar hkd-config-1.0.jar
#RUN sh -c 'touch /hkd-config-1.0.jar'
#ENV JAVA_OPTS=""
#ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /hkd-config-1.0.jar" ]


# tag:0.4
FROM idocker.io/jre:1.8.0_212
VOLUME /tmp
ADD target/hkd-config-1.0.jar hkd-config-1.0.jar
RUN sh -c 'touch /hkd-config-1.0.jar'
ENV JAVA_OPTS=""
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /hkd-config-1.0.jar" ]

然后使用提交到gitlab,使用jenkins打包,编译,制作docker镜像提交到nexus仓库,接下来是在kuboard界面上操作
postStart上使用UP

preStop使用Down

kuboard界面上显示

日志显示;

关键分析:日志显示中的区别

使用命令down后,关闭这行pod,启用一个新pod,这中间间隔的时间太短了,会有问题,还有待改善

暂定改善方法:在preStop中增加等待时间
直接加命令后添加sleep等待时间报错:


1.这个日志表述的含义是在关闭pod之前执行preStop中的down命令,eureka注册中心仍会显示这个服务,但是状态是DOWN
2020-07-01 17:31:28.369 INFO 1 --- [nio-8761-exec-1] c.n.e.r.InstanceResource : Status updated: HKD-CONFIG - cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888 - DOWN

2.这个日志表述的含义是pod关闭导致这个服务停止了,eureka注册中心不显示这个服务
2020-07-01 17:31:28.796 INFO 1 --- [io-8761-exec-10] c.n.e.r.AbstractInstanceRegistry : Registered instance HKD-CONFIG/cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888 with status DOWN (replication=false)

3.这个日志表述的含义是启动pod时,preStart中的up命令,eureka中状态改成up
2020-07-01 17:31:46.688 INFO 1 --- [nio-8761-exec-7] c.n.e.r.InstanceResource : Status updated: HKD-CONFIG - cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888 - UP

4.这个日志表述的是含义是启动pod,config服务往eureka上注册,也就是显示出来
2020-07-01 17:32:04.033 INFO 1 --- [nio-8761-exec-1] c.n.e.r.AbstractInstanceRegistry : Registered instance HKD-CONFIG/cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888 with status UP (replication=false)

如下是单独使用命令操作的日志显示

down

执行的命令

eureka日志查看

eureka界面查看

up

执行的命令

eureka日志查看

eureka界面查看

关于上面所说的间隔时间太短的问题处理
可以使用如下方法进行:

# postStart命令
curl -X PUT http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=UP;sleep 300

# preStop命令
curl -v -X PUT http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=DOWN;sleep 300

yaml文件:

          lifecycle:
            postStart:
              exec:
                command:
                  - /bin/sh
                  - '-c'
                  - >-
                    curl -X PUT
                    http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=UP;sleep
                    300
            preStop:
              exec:
                command: 
                  - /bin/sh
                  - '-c'
                  - >-
                    curl -v -X PUT
                    http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=DOWN;sleep
                    300

或者换成如下这俩命令,功能都是一样的,只不过显示有些区别

          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh","-c","curl -v -X PUT http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=UP;sleep 300"]
            preStop:
              exec:
                command: ["/bin/sh","-c","curl -v -X PUT http://cloud-eureka-0.cloud-eureka.test.svc.cluster.local:8761/eureka/apps/HKD-CONFIG/cloud-config-0.cloud-config.test.svc.cluster.local:hkd-config:8888/status?value=DOWN;sleep 300"]

pod开始启动时,先执行postStart中的命令,此时,服务是先注册到eureka中,状态是up,但是服务还没有启动,需要等待300秒后才开始启动

pod删除时,先执行preStop中的命令,把服务从eureka中摘除,然后等待300面后删除pod,但是有个很严重的问题:把服务从eureka中摘除,若是有副本pod,这俩pod都会从eureka中摘除,但是只会删除一个pod,另一个pod虽在运行,但是没有注册到eureka中

参考文章:
这篇文章是使用纯命令的形式
https://www.cnblogs.com/sunsky303/p/11571545.html

这篇文章是使用命令执行脚本的形式
https://gitee.com/sunshanpeng/blog/blob/master/在k8s中使用eureka的几种姿势.md

posted @ 2020-06-30 11:24  三度  阅读(363)  评论(0编辑  收藏