使用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
说明：
- http://cloud-eureka-0.cloud-eureka.hkd.svc.cluster.local:8761 这个是eureka注册中心地址
- cloud-config-0.cloud-config.hkd.svc.cluster.local:hkd-config:8888 这个是config的地址，可以在如下这个界面中查看到
修改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
