在Kubernetes上部署应用时我们常忽略的几件事 (2)

来看个例子，这里以常用的 TCP存活探测为例

apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx-demo image: nginx livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 10 periodSeconds: 10 readinessProbe: tcpSocket: port: 80 initialDelaySeconds: 10 periodSeconds: 10 livenessProbe 部分定义如何执行 Liveness 探测： 1. 探测的方法是：通过tcpSocket连接nginx的80端口。如果执行成功，返回值为零，Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。 2. initialDelaySeconds: 10 指定容器启动 10 之后开始执行 Liveness 探测，一般会根据应用启动的准备时间来设置。比如应用正常启动要花 30 秒，那么 initialDelaySeconds 的值就应该大于 30。 3. periodSeconds: 10 指定每 10 秒执行一次 Liveness 探测。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，则会杀掉并重启容器。 readinessProbe 探测一样，但是 readiness 的 READY 状态会经历了如下变化： 1. 刚被创建时，READY 状态为不可用。 2. 20 秒后（initialDelaySeconds + periodSeconds），第一次进行 Readiness 探测并成功返回，设置 READY 为可用。 3. 如果Kubernetes连续 3 次 Readiness 探测均失败后，READY 被设置为不可用。 为Pod设置默认的网络策略

Kubernetes使用一种“扁平”的网络拓扑，默认情况下，所有Pod都可以直接相互通信。 但是在某些情况下我们不希望这样，甚至是不必要的。 会存在一些潜在的安全隐患，例如一个易受攻击的应用程序被利用，则可以为攻击者提供完全访问权限，以将流量发送到网络上的所有pod。 像在许多安全领域中一样，最小访问策略也适用于此，理想情况下，将创建网络策略以明确指定允许哪些容器到容器的连接。

举例，以下是一个简单的策略，该策略将拒绝特定名称空间的所有入口流量

--- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress-flow spec: podSelector: {} policyTypes: - Ingress

此配置的示意图

通过Hooks和init容器的自定义行为

我们使用Kubernetes系统的主要目标之一就是尝试为现成的开发人员提供尽可能零停机的部署。 由于应用程序关闭自身和清理已利用资源的方式多种多样，因此这很困难。 我们遇到特别困难的一个应用是Nginx。 我们注意到，当我们启动这些Pod的滚动部署时，活动连接在成功终止之前被丢弃。 经过广泛的在线研究，事实证明，Kubernetes并没有等待Nginx在终止Pod之前耗尽其连接。 使用停止前挂钩，我们能够注入此功能，并通过此更改实现了零停机时间。

通常情况下，比如我们要对Nginx进行滚动升级，但是Kubernetes在停止Pod之前并不会等待Nginx终止连接。这就会导致被停掉的nginx并没有正确关闭所有连接，这样是不合理的。所以我们需要在停止钱使用钩子，以解决这样的问题。

我们可以在部署文件添加lifecycle

lifecycle: preStop: exec: command: ["/usr/local/bin/nginx-killer.sh"]

nginx-killer.sh

#!/bin/bash sleep 3 PID=$(cat /run/nginx.pid) nginx -s quit while [ -d /proc/$PID ]; do echo "Waiting while shutting down nginx..." sleep 10 done

这样，Kubernetes在关闭Pod之前，会执行nginx-killer.sh脚本，以我们定义的方式关闭nginx

另外一种情况就是使用init容器
Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动
例如：

initContainers: - name: init image: busybox command: ["chmod","777","-R","/var/www/html"] imagePullPolicy: Always volumeMounts: - name: volume mountPath: /var/www/html containers: - name: nginx-demo image: nginx ports: - containerPort: 80 name: port volumeMounts: - name: volume mountPath: /var/www/html

我们给nginx的/var/www/html挂载了一块数据盘，在主容器运行前，我们把/var/www/html权限改成777，以便主容器使用时不会存在权限问题。
当然这里只是一个小栗子，Init Container更多强大的功能，比如初始化配置等。。。

Kernel Tuning（内核参数优化）

最后，将更先进的技术留给最后，哈哈
Kubernetes是一个非常灵活的平台，旨在让你以自己认为合适的方式运行服务。通常如果我们有高性能的服务，对资源要求比较严苛，比如常见的redis，启动以后会有如下提示

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.