CloudNative|云原生应用架构|云原生架构|容器化架构|微服务架构|平台架构|基础架构

前言

最近上了k8s后，给开发提供dashboard访问，发现有不少开发无法使用chrome访问，出现问题的大部分都是使用的windows系统，主要有以下两类问题，这里记录下如何解决

ERR_SSL_SERVER_CERT_BAD_FORMAT

解决方法：重新安装chrome最新版本解决

NET::ERR_CERT_INVALID

解决方法：创建chrome桌面快捷方式，然后到桌面：右键chrome–>属性–>在目标后面添加如下：--disable-infobars --ignore-certificate-errors

示例："C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-infobars --ignore-certificate-errors

环境介绍

环境初始化

修改hosts信息，在所有master机器上运行

1
2
3
4
5

cat <<EOF >> /etc/hosts
172.19.170.183 master-1
172.19.170.184 master-2
172.19.170.185 master-3
EOF

在master-1 机器上执行以下命令：

1
2
3

ssh-keygen -t rsa
ssh-copy-id root@master-2
ssh-copy-id root@master-3

环境介绍

环境初始化

在master-1 机器上执行以下命令：

1
2
3

ssh-keygen -t rsa
ssh-copy-id root@master-2
ssh-copy-id root@master-3

修改hosts信息，在所有master机器上运行

1
2
3
4
5

echo <<EOF >> /etc/hosts
172.19.170.183 master-1
172.19.170.184 master-2
172.19.170.185 master-3
EOF

kube-scheduler 是 Kubernetes 中负责调度的组件，它本身的调度功能已经很强大了。但由于 Kubernetes 集群非常活跃，它的状态会随时间而改变，由于各种原因，你可能需要将已经运行的 Pod 移动到其他节点：

• 某些节点负载过高
• 某些资源对象被添加了 node 亲和性 或 pod （反）亲和性
• 集群中加入了新节点

一旦 Pod 启动之后 kube-scheduler 便不会再尝试重新调度它。根据环境的不同，你可能会有很多需要手动调整 Pod 的分布，例如：如果集群中新加入了一个节点，那么已经运行的 Pod 并不会被分摊到这台节点上，这台节点可能只运行了少量的几个 Pod，这并不理想，对吧？

Descheduler 如何工作？

Descheduler 会检查 Pod 的状态，并根据自定义的策略将不满足要求的 Pod 从该节点上驱逐出去。Descheduler 并不是 kube-scheduler 的替代品，而是要依赖于它。该项目目前放在 Kubernetes 的孵化项目中，还没准备投入生产，但经过我实验发现它的运行效果很好，而且非常稳定。那么该如何安装呢？

前言

毫无疑问，我们希望正确处理客户端请求。当pod正在启动或关闭时，我们显然不希望看到断开的连接。Kubernetes本身并不能确保这种情况永远不会发生。您的应用需要遵循一些规则以防止断开连接。本文讨论这些规则。

确保正确处理所有客户端请求

我们先从访问Pod的客户端的视角来看看Pod的生命周期（客户端使用pod提供的服务）。我们希望确保客户的请求得到妥善处理，因为如果当pod启动或关闭时连接开始中断，我们就会遇到麻烦。Kubernetes本身并不保证不会发生这种情况，所以让我们看看我们需要做些什么来防止它发生。

当Pod启动时阻止连接中断

如果你理解services和service endpoints的工作原理，确保在pod启动时正确处理每个连接都非常简单。当pod启动时，它会作为一个endpoints被添加到所有匹配该Pod标签的Services里。Pod也会发出信号告诉Kubernetes它已就绪。只有它变成一个service endpoints时才可以接收来自客户端的请求。

如果你没有在Pod Spec里指定readiness探针，则会始终认为该pod已准备就绪。这意味着它将立即开始接收请求 - 只要第一个Kube-Proxy在其节点上更新iptables规则并且第一个客户端pod尝试连接到该服务。如果那个时候你的应用并没有做好接收请求的准备，那么客户端将会见到“connection refused”类型的错误。

你所需要做的就是保证你的readiness探针当且仅当你的应用可以正确处理收到的请求时才返回成功结果。所以添加一个HTTP GET readiness探针并让它指向你应用的基础URL会是一个很好的开始。在很多情况下，这可以让你省去实现一个特定的readiness端点的工作量。