关于网站关停的申请,填报wordpress模板,aspx网站模板,重庆seo排名方法目录 1 本人基础环境2 目的3 存活、就绪和启动探针介绍3.1 存活探针3.2 就绪探针3.3 启动探针 4 探针使用场景4.1 存活探针4.2 就绪探针4.3 启动探针 5 配置存活、就绪和启动探针5.1 定义存活探针5.2 定义一个存活态 HTTP 请求接口5.3 定义 TCP 的就绪探针、存活探测5.4 定义 g… 目录 1 本人基础环境2 目的3 存活、就绪和启动探针介绍3.1 存活探针3.2 就绪探针3.3 启动探针 4 探针使用场景4.1 存活探针4.2 就绪探针4.3 启动探针 5 配置存活、就绪和启动探针5.1 定义存活探针5.2 定义一个存活态 HTTP 请求接口5.3 定义 TCP 的就绪探针、存活探测5.4 定义 gRPC 存活探针 6 使用场景6.1 使用启动探针保护慢启动容器6.2 定义就绪探针 7 Probe的配置字段7.1 HTTP 探测配置7.2 TCP 探测配置 1 本人基础环境
操作系统CentOSStream9 CPU - 2核 内存 - 4GB 硬盘 - 60G安装了docker及k8sCentOS9安装docker及k8s
2 目的
介绍存活Liveness、就绪Readiness和启动Startup探针如何给容器配置存活Liveness、就绪Readiness和启动Startup探针。
3 存活、就绪和启动探针介绍
3.1 存活探针
存活探针决定何时重启容器。 例如当应用在运行但无法取得进展时存活探针可以捕获这类死锁。
如果一个容器的存活探针失败多次kubelet 将重启该容器。
存活探针不会等待就绪探针成功。 如果你想在执行存活探针前等待你可以定义 initialDelaySeconds或者使用启动探针。
3.2 就绪探针
就绪探针决定何时容器准备好开始接受流量。 这种探针在等待应用执行耗时的初始任务时非常有用例如建立网络连接、加载文件和预热缓存。
如果就绪探针返回的状态为失败Kubernetes 会将该 Pod 从所有对应服务的端点中移除。
就绪探针在容器的整个生命期内持续运行。
3.3 启动探针
启动探针检查容器内的应用是否已启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被 kubelet 杀掉。
如果配置了这类探针它会禁用存活检测和就绪检测直到启动探针成功为止。
这类探针仅在启动时执行不像存活探针和就绪探针那样周期性地运行。
4 探针使用场景
4.1 存活探针
kubelet 使用存活探针来确定什么时候要重启容器。 例如存活探针可以探测到应用死锁应用在运行但是无法继续执行后面的步骤情况。 重启这种状态下的容器有助于提高应用的可用性即使其中存在缺陷。
4.2 就绪探针
kubelet 使用就绪探针可以知道容器何时准备好接受请求流量。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 当 Pod 的 Ready 状况 为 true 时Pod 被认为是就绪的。若 Pod 未就绪会被从 Service 的负载均衡器中剔除。 当 Pod 所在节点的 Ready 状况不为 true 时、当 Pod 的某个 readinessGates 为 false 时或者当 Pod 中有任何一个容器未就绪时Pod 的 Ready 状况为 false。
4.3 启动探针
kubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针存活探针和就绪探针在启动探针成功之前不会启动从而确保存活探针或就绪探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被杀掉。 注意 存活探针是一种从应用故障中恢复的强劲方式但应谨慎使用。 你必须仔细配置存活探针确保它能真正标示出不可恢复的应用故障例如死锁。 说明 错误的存活探针可能会导致级联故障。 这会导致在高负载下容器重启例如由于应用无法扩展导致客户端请求失败以及由于某些 Pod 失败而导致剩余 Pod 的工作负载增加。了解就绪探针和存活探针之间的区别 以及何时为应用配置使用它们非常重要。 5 配置存活、就绪和启动探针
5.1 定义存活探针
许多长时间运行的应用最终会进入损坏状态除非重新启动否则无法被恢复。 Kubernetes 提供了存活探针来发现并处理这种情况。
在本练习中你会创建一个 Pod其中运行一个基于 registry.k8s.io/busybox 镜像的容器。 下面是这个 Pod 的配置文件。
# pods/probe/exec-liveness.yaml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: registry.k8s.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5在这个配置文件中可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值kubelet 会杀死这个容器并重新启动它。
当容器启动时执行如下的命令
/bin/sh -c touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600这个容器生命的前 30 秒/tmp/healthy 文件是存在的。 所以在这最开始的 30 秒内执行命令 cat /tmp/healthy 会返回成功代码。 30 秒之后执行命令 cat /tmp/healthy 就会返回失败代码。
创建 Pod
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml在 30 秒内查看 Pod 的事件
kubectl describe pod liveness-exec输出结果表明还没有存活探针失败
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 11s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 9s kubelet, node01 Pulling image registry.k8s.io/busybox
Normal Pulled 7s kubelet, node01 Successfully pulled image registry.k8s.io/busybox
Normal Created 7s kubelet, node01 Created container liveness
Normal Started 7s kubelet, node01 Started container liveness35 秒之后再来看 Pod 的事件
kubectl describe pod liveness-exec在输出结果的最下面有信息显示存活探针失败了这个失败的容器被杀死并且被重建了。
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 57s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 55s kubelet, node01 Pulling image registry.k8s.io/busybox
Normal Pulled 53s kubelet, node01 Successfully pulled image registry.k8s.io/busybox
Normal Created 53s kubelet, node01 Created container liveness
Normal Started 53s kubelet, node01 Started container liveness
Warning Unhealthy 10s (x3 over 20s) kubelet, node01 Liveness probe failed: cat: cant open /tmp/healthy: No such file or directory
Normal Killing 10s kubelet, node01 Container liveness failed liveness probe, will be restarted再等 30 秒确认这个容器被重启了
kubectl get pod liveness-exec输出结果显示 RESTARTS 的值增加了 1。 请注意一旦失败的容器恢复为运行状态RESTARTS 计数器就会增加 1
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m5.2 定义一个存活态 HTTP 请求接口
另外一种类型的存活探测方式是使用 HTTP GET 请求。 下面是一个 Pod 的配置文件其中运行一个基于 registry.k8s.io/e2e-test-images/agnhost 镜像的容器。
# pods/probe/http-liveness.yaml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: registry.k8s.io/e2e-test-images/agnhost:2.40args:- livenesslivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3在这个配置文件中你可以看到 Pod 也只有一个容器。 periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务服务在监听 8080 端口发送一个 HTTP GET 请求来执行探测。 如果服务器上 /healthz 路径下的处理程序返回成功代码则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码则 kubelet 会杀死这个容器并将其重启。
返回大于或等于 200 并且小于 400 的任何代码都标示成功其它返回代码都标示失败。
你可以访问 server.go 阅读服务的源码。 容器存活期间的最开始 10 秒中/healthz 处理程序返回 200 的状态码。 之后处理程序返回 500 的状态码。
http.HandleFunc(/healthz, func(w http.ResponseWriter, r *http.Request) {duration : time.Now().Sub(started)if duration.Seconds() 10 {w.WriteHeader(500)w.Write([]byte(fmt.Sprintf(error: %v, duration.Seconds())))} else {w.WriteHeader(200)w.Write([]byte(ok))}
})kubelet 在容器启动之后 3 秒开始执行健康检查。所以前几次健康检查都是成功的。 但是 10 秒之后健康检查会失败并且 kubelet 会杀死容器再重新启动容器。
创建一个 Pod 来测试 HTTP 的存活检测
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml10 秒之后通过查看 Pod 事件来确认存活探针已经失败并且容器被重新启动了。
kubectl describe pod liveness-http5.3 定义 TCP 的就绪探针、存活探测
第三种类型的存活探测是使用 TCP 套接字。 使用这种配置时kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接这个容器就被看作是健康的如果不能则这个容器就被看作是有问题的。
apiVersion: v1
kind: Pod
metadata:name: goproxylabels:app: goproxy
spec:containers:- name: goproxyimage: registry.k8s.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 10如你所见TCP 检测的配置和 HTTP 检测非常相似。 下面这个例子同时使用就绪探针和存活探针。kubelet 会在容器启动 15 秒后运行第一次存活探测。 此探测会尝试连接 goproxy 容器的 8080 端口。 如果此存活探测失败容器将被重启。kubelet 将继续每隔 10 秒运行一次这种探测。
除了存活探针这个配置还包括一个就绪探针。 kubelet 会在容器启动 15 秒后运行第一次就绪探测。 与存活探测类似就绪探测会尝试连接 goproxy 容器的 8080 端口。 如果就绪探测失败Pod 将被标记为未就绪且不会接收来自任何服务的流量。
要尝试 TCP 存活检测运行以下命令创建 Pod
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml15 秒之后通过查看 Pod 事件来检测存活探针
kubectl describe pod goproxy5.4 定义 gRPC 存活探针
如果你的应用实现了 gRPC 健康检查协议 这个例子展示了如何配置 Kubernetes 以将其用于应用的存活性检查。 类似地你可以配置就绪探针和启动探针。
下面是一个示例清单
# pods/probe/grpc-liveness.yaml
apiVersion: v1
kind: Pod
metadata:name: etcd-with-grpc
spec:containers:- name: etcdimage: registry.k8s.io/etcd:3.5.1-0command: [ /usr/local/bin/etcd, --data-dir, /var/lib/etcd, --listen-client-urls, http://0.0.0.0:2379, --advertise-client-urls, http://127.0.0.1:2379, --log-level, debug]ports:- containerPort: 2379livenessProbe:grpc:port: 2379initialDelaySeconds: 10要使用 gRPC 探针必须配置 port 属性。 如果要区分不同类型的探针和不同功能的探针可以使用 service 字段。 你可以将 service 设置为 liveness并使你的 gRPC 健康检查端点对该请求的响应与将 service 设置为 readiness 时不同。 这使你可以使用相同的端点进行不同类型的容器健康检查而不是监听两个不同的端口。 如果你想指定自己的自定义服务名称并指定探测类型Kubernetes 项目建议你使用使用一个可以关联服务和探测类型的名称来命名。 例如myservice-liveness使用 - 作为分隔符。 说明 与 HTTP 或 TCP 探针不同gRPC 探测不能按名称指定健康检查端口 也不能自定义主机名。 配置问题例如错误的 port 或 service、未实现健康检查协议 都被认作是探测失败这一点与 HTTP 和 TCP 探针类似。
kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml15 秒钟之后查看 Pod 事件确认存活性检查结果
kubectl describe pod etcd-with-grpc当使用 gRPC 探针时需要注意以下一些技术细节
这些探针运行时针对的是 Pod 的 IP 地址或其主机名。 请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。这些探针不支持任何身份认证参数例如 -tls。对于内置的探针而言不存在错误代码。所有错误都被视作探测失败。如果 ExecProbeTimeout 特性门控被设置为 false则 grpc-health-probe 不会考虑 timeoutSeconds 设置状态默认值为 1s 而内置探针则会在超时时返回失败。
工作原理 当Kubernetes配置了gRPC存活探针后它会定期向指定的gRPC端口发送健康检查请求。如果应用程序能够正常响应这些请求则表明应用程序是健康的如果应用程序无法响应或响应不符合预期则Kubernetes会认为应用程序已经崩溃或不再存活并会根据容器的重启策略重新启动容器。
6 使用场景
6.1 使用启动探针保护慢启动容器
有时候会有一些现有的应用在启动时需要较长的初始化时间。 在这种情况下若要不影响对死锁作出快速响应的探测设置存活探测参数是要技巧的。 解决办法是使用相同的命令来设置启动探测针对 HTTP 或 TCP 检测可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对最糟糕情况下的启动时间。
比如
ports:
- name: liveness-portcontainerPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 1periodSeconds: 10startupProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 30periodSeconds: 10对于 HTTP 和 TCP 存活检测可以使用命名的 portgRPC 探针不支持使用命名端口。 幸亏有启动探测应用将会有最多 5 分钟30 * 10 300s的时间来完成其启动过程。 一旦启动探测成功一次存活探测任务就会接管对容器的探测对容器死锁作出快速响应。 如果启动探测一直没有成功容器会在 300 秒后被杀死并且根据 restartPolicy 来执行进一步处置。 failureThreshold参数定义了探针在连续失败多少次后才将容器视为不健康或未就绪。 periodSeconds参数定义了探针存活探针、就绪探针或启动探针多长时间执行一次健康检查。 6.2 定义就绪探针
有时候应用会暂时性地无法为请求提供服务。 例如应用在启动时可能需要加载大量的数据或配置文件或是启动后要依赖等待外部服务。 在这种情况下既不想杀死应用也不想给它发送请求。 Kubernetes 提供了就绪探针来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息并且不接受通过 Kubernetes Service 的流量。 说明 就绪探针在容器的整个生命周期中保持运行状态。 注意 存活探针与就绪性探针相互间不等待对方成功。 如果要在执行就绪性探针之前等待应该使用 initialDelaySeconds 或 startupProbe。 就绪探针的配置和存活探针的配置相似。 唯一区别就是要使用 readinessProbe 字段而不是 livenessProbe 字段。
readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5HTTP 和 TCP 的就绪探针配置也和存活探针的配置完全相同。
就绪和存活探测可以在同一个容器上并行使用。 两者共同使用可以确保流量不会发给还未就绪的容器当这些探测失败时容器会被重新启动。
7 Probe的配置字段
Probe 有很多配置字段可以使用这些字段精确地控制启动、存活和就绪检测的行为 initialDelaySeconds容器启动后要等待多少秒后才启动启动、存活和就绪探针。 如果定义了启动探针则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。 如果 periodSeconds 的值大于 initialDelaySeconds则 initialDelaySeconds 将被忽略。默认是 0 秒最小值是 0。 periodSeconds执行探测的时间间隔单位是秒。默认是 10 秒。最小值是 1。 当容器未就绪时ReadinessProbe 可能会在除配置的 periodSeconds 间隔以外的时间执行。这是为了让 Pod 更快地达到可用状态。 timeoutSeconds探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 successThreshold探针在失败后被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1 failureThreshold探针连续失败了 failureThreshold 次之后 Kubernetes 认为总体上检查已失败容器状态未就绪、不健康、不活跃。 默认值为 3最小值为 1。 对于启动探针或存活探针而言如果至少有 failureThreshold 个探针已失败 Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 遵循该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针kubelet 继续运行检查失败的容器并继续运行更多探针 因为检查失败kubelet 将 Pod 的 Ready 状况设置为 false。 terminationGracePeriodSeconds为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。 默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值如果不设置则为 30 秒最小值为 1。 注意 如果就绪态探针的实现不正确可能会导致容器中进程的数量不断上升。 如果不对其采取措施很可能导致资源枯竭的状况 7.1 HTTP 探测配置
HTTP Probes 允许针对 httpGet 配置额外的字段
host连接使用的主机名默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替scheme用于设置连接主机的方式HTTP 还是 HTTPS。默认是 “HTTP”。path访问 HTTP 服务的路径。默认值为 “/”。httpHeaders请求中自定义的 HTTP 头。HTTP 头字段允许重复。port访问容器的端口号或者端口名。如果数字必须在 165535 之间。
对于 HTTP 探测kubelet 发送一个 HTTP 请求到指定的端口和路径来执行检测。 除非 httpGet 中的 host 字段设置了否则 kubelet 默认是给 Pod 的 IP 地址发送探测。 如果 scheme 字段设置为了 HTTPSkubelet 会跳过证书验证发送 HTTPS 请求。 大多数情况下不需要设置 host 字段。 这里有个需要设置 host 字段的场景假设容器监听 127.0.0.1并且 Pod 的 hostNetwork 字段设置为了 true。那么 httpGet 中的 host 字段应该设置为 127.0.0.1。 可能更常见的情况是如果 Pod 依赖虚拟主机你不应该设置 host 字段而是应该在 httpHeaders 中设置 Host。 当将Pod的hostNetwork字段设置为true时该Pod将与其所在节点Node共享网络命名空间。这意味着Pod将使用主机的网络栈和IP地址而不是由Kubernetes创建并管理的专用网络栈。 针对 HTTP 探针kubelet 除了必需的 Host 头部之外还发送两个请求头部字段
User-Agent默认值是 kube-probe/1.32其中 1.32 是 kubelet 的版本号。Accept默认值 /。
你可以通过为探测设置 httpHeaders 来重载默认的头部字段值。例如
livenessProbe:httpGet:httpHeaders:- name: Acceptvalue: application/jsonstartupProbe:httpGet:httpHeaders:- name: User-Agentvalue: MyUserAgent你也可以通过将这些头部字段定义为空值从请求中去掉这些头部字段。
livenessProbe:httpGet:httpHeaders:- name: Acceptvalue: startupProbe:httpGet:httpHeaders:- name: User-Agentvalue: 注意 当 kubelet 使用 HTTP 探测 Pod 时仅当重定向到同一主机时它才会遵循重定向。 如果 kubelet 在探测期间收到 11 个或更多重定向则认为探测成功并创建相关事件
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 29m default-scheduler Successfully assigned default/httpbin-7b8bc9cb85-bjzwn to daocloudNormal Pulling 29m kubelet Pulling image docker.io/kennethreitz/httpbinNormal Pulled 24m kubelet Successfully pulled image docker.io/kennethreitz/httpbin in 5m12.402735213sNormal Created 24m kubelet Created container httpbinNormal Started 24m kubelet Started container httpbinWarning ProbeWarning 4m11s (x1197 over 24m) kubelet Readiness probe warning: Probe terminated redirects
如果 kubelet 收到主机名与请求不同的重定向则探测结果将被视为成功并且 kubelet 将创建一个事件来报告重定向失败。
7.2 TCP 探测配置
对于 TCP 探测而言kubelet 在节点上不是在 Pod 里面发起探测连接 这意味着你不能在 host 参数上配置服务名称因为 kubelet 不能解析服务名称。
探针层面的 terminationGracePeriodSeconds 在 1.25 及以上版本中用户可以指定一个探针层面的 terminationGracePeriodSeconds 作为探针规约的一部分。 当 Pod 层面和探针层面的 terminationGracePeriodSeconds 都已设置kubelet 将使用探针层面设置的值。
当设置 terminationGracePeriodSeconds 时请注意以下事项
kubelet 始终优先选用探针级别 terminationGracePeriodSeconds 字段 如果它存在于 Pod 上。如果你已经为现有 Pod 设置了 terminationGracePeriodSeconds 字段并且不再希望使用针对每个探针的终止宽限期则必须删除现有的这类 Pod。
例如
spec:terminationGracePeriodSeconds: 3600 # Pod 级别设置containers:- name: testimage: ...ports:- name: liveness-portcontainerPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 1periodSeconds: 60# 重载 Pod 级别的 terminationGracePeriodSecondsterminationGracePeriodSeconds: 60探针层面的 terminationGracePeriodSeconds 不能用于就绪态探针。 这一设置将被 API 服务器拒绝。 文章转载自： http://www.morning.bplqh.cn.gov.cn.bplqh.cn http://www.morning.fqsxf.cn.gov.cn.fqsxf.cn http://www.morning.ymjgx.cn.gov.cn.ymjgx.cn http://www.morning.hqpyt.cn.gov.cn.hqpyt.cn http://www.morning.ns3nt8.cn.gov.cn.ns3nt8.cn http://www.morning.touziyou.cn.gov.cn.touziyou.cn http://www.morning.kwdfn.cn.gov.cn.kwdfn.cn http://www.morning.kmqjx.cn.gov.cn.kmqjx.cn http://www.morning.mftdq.cn.gov.cn.mftdq.cn http://www.morning.nllst.cn.gov.cn.nllst.cn http://www.morning.guofenmai.cn.gov.cn.guofenmai.cn http://www.morning.dbqg.cn.gov.cn.dbqg.cn http://www.morning.cwwbm.cn.gov.cn.cwwbm.cn http://www.morning.mspkz.cn.gov.cn.mspkz.cn http://www.morning.smwlr.cn.gov.cn.smwlr.cn http://www.morning.pyswr.cn.gov.cn.pyswr.cn http://www.morning.cwqrj.cn.gov.cn.cwqrj.cn http://www.morning.jpzcq.cn.gov.cn.jpzcq.cn http://www.morning.fydsr.cn.gov.cn.fydsr.cn http://www.morning.ddrdt.cn.gov.cn.ddrdt.cn http://www.morning.wlgpz.cn.gov.cn.wlgpz.cn http://www.morning.cwtrl.cn.gov.cn.cwtrl.cn http://www.morning.zbgqt.cn.gov.cn.zbgqt.cn http://www.morning.gzgwn.cn.gov.cn.gzgwn.cn http://www.morning.nlysd.cn.gov.cn.nlysd.cn http://www.morning.wjpsn.cn.gov.cn.wjpsn.cn http://www.morning.cxnyg.cn.gov.cn.cxnyg.cn http://www.morning.zrmxp.cn.gov.cn.zrmxp.cn http://www.morning.rhdln.cn.gov.cn.rhdln.cn http://www.morning.jzfxk.cn.gov.cn.jzfxk.cn http://www.morning.ljdjn.cn.gov.cn.ljdjn.cn http://www.morning.wqbfd.cn.gov.cn.wqbfd.cn http://www.morning.qlpyn.cn.gov.cn.qlpyn.cn http://www.morning.dycbp.cn.gov.cn.dycbp.cn http://www.morning.rgfx.cn.gov.cn.rgfx.cn http://www.morning.wnbpm.cn.gov.cn.wnbpm.cn http://www.morning.pmlgr.cn.gov.cn.pmlgr.cn http://www.morning.pmlgr.cn.gov.cn.pmlgr.cn http://www.morning.pbsqr.cn.gov.cn.pbsqr.cn http://www.morning.qwfq.cn.gov.cn.qwfq.cn http://www.morning.tnbas.com.gov.cn.tnbas.com http://www.morning.jzykq.cn.gov.cn.jzykq.cn http://www.morning.kspfq.cn.gov.cn.kspfq.cn http://www.morning.fnssm.cn.gov.cn.fnssm.cn http://www.morning.rxhn.cn.gov.cn.rxhn.cn http://www.morning.tkrwm.cn.gov.cn.tkrwm.cn http://www.morning.xkppj.cn.gov.cn.xkppj.cn http://www.morning.xshkh.cn.gov.cn.xshkh.cn http://www.morning.rbtny.cn.gov.cn.rbtny.cn http://www.morning.gydsg.cn.gov.cn.gydsg.cn http://www.morning.ftcrt.cn.gov.cn.ftcrt.cn http://www.morning.xqjrg.cn.gov.cn.xqjrg.cn http://www.morning.pxrfm.cn.gov.cn.pxrfm.cn http://www.morning.smpb.cn.gov.cn.smpb.cn http://www.morning.qbtj.cn.gov.cn.qbtj.cn http://www.morning.jqjnl.cn.gov.cn.jqjnl.cn http://www.morning.yymlk.cn.gov.cn.yymlk.cn http://www.morning.jfbgn.cn.gov.cn.jfbgn.cn http://www.morning.jyknk.cn.gov.cn.jyknk.cn http://www.morning.sbpt.cn.gov.cn.sbpt.cn http://www.morning.rfpb.cn.gov.cn.rfpb.cn http://www.morning.rqqct.cn.gov.cn.rqqct.cn http://www.morning.zpyxl.cn.gov.cn.zpyxl.cn http://www.morning.brwwr.cn.gov.cn.brwwr.cn http://www.morning.yhsrp.cn.gov.cn.yhsrp.cn http://www.morning.brkrt.cn.gov.cn.brkrt.cn http://www.morning.vvbsxm.cn.gov.cn.vvbsxm.cn http://www.morning.qinhuangdjy.cn.gov.cn.qinhuangdjy.cn http://www.morning.ldhbs.cn.gov.cn.ldhbs.cn http://www.morning.ftrpvh.cn.gov.cn.ftrpvh.cn http://www.morning.fjlsfs.com.gov.cn.fjlsfs.com http://www.morning.sgwr.cn.gov.cn.sgwr.cn http://www.morning.kmldm.cn.gov.cn.kmldm.cn http://www.morning.npgwb.cn.gov.cn.npgwb.cn http://www.morning.mwbqk.cn.gov.cn.mwbqk.cn http://www.morning.hdzty.cn.gov.cn.hdzty.cn http://www.morning.ychrn.cn.gov.cn.ychrn.cn http://www.morning.jrrqs.cn.gov.cn.jrrqs.cn http://www.morning.xyjlh.cn.gov.cn.xyjlh.cn http://www.morning.cbnlg.cn.gov.cn.cbnlg.cn
