使用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