发表于 | 分类于 ， | | 热度: ℃
字数统计: 4,252 字 | 阅读时长 ≈ 19 分钟

前言

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的，我们就不希望对外的一些服务和内部的服务跑在同一个节点上了，害怕内部服务对外部的服务产生影响；但是有的时候我们的服务之间交流比较频繁，又希望能够将这两个服务的 Pod 调度到同一个的节点上。这就需要用到 Kubernetes 里面的一个概念：亲和性和反亲和性。

亲和性有分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。

nodeSelector

在了解亲和性之前，我们先来了解一个非常常用的调度方式：nodeSelector。我们知道label是kubernetes中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的一个就是 service 通过匹配 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。

我们可以通过下面的命令查看我们的 node 的 label：

1
2
3
4
5
$ kubectl get nodes --show-labels
NAME      STATUS    ROLES     AGE       VERSION   LABELS
master    Ready     master    147d      v1.10.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02    Ready     <none>    67d       v1.10.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,course=k8s,kubernetes.io/hostname=node02
node03    Ready     <none>    127d      v1.10.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03

现在我们先给节点node02增加一个com=youdianzhishi的标签，命令如下：

1
2
$ kubectl label nodes node02 com=youdianzhishi
node "node02" labeled

阅读全文 »

发表于 | 分类于 ， ， | | 热度: ℃
字数统计: 3,765 字 | 阅读时长 ≈ 21 分钟

前言（坑）

负载均衡问题

  • 阿里不支持LVS，没有vip可用，必须通过申请SLB来固定VIP
  • 因Kubernetes apiserver为https协议，阿里SLB中能负载均衡HTTPS的只有TCP方式，但TCP协议不能转发到发起主机（apiserver 需要有回环路访问，简单说就是自己给自己发请求）

为了解决kubernets apiserver高可用问题，故用以下方式来解决：

  • 申请一个内网的SLB（获取VIP），8443为监听端口，6443为apiserver的后端端口
  • 在每台master机器上搭建keepalived+haproxy，VIP 用SLB的VIP

环境介绍

IP Hostname 备注
172.19.170.183 master-1 安装keepalived + haproxy
172.19.170.184 master-2 安装keepalived + haproxy
172.19.170.185 master-3 安装keepalived + haproxy
172.19.170.186 node-1 无
172.19.170.187 node-2 无
172.19.170.100 vip 申请阿里云的SLB获取到

环境初始化

修改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
阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 2,774 字 | 阅读时长 ≈ 10 分钟

kube-scheduler 简介

kube-scheduler是 kubernetes 系统的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是我们选择使用 kubernetes 一个非常重要的理由。如果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。

调度流程

默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，我们前面和大家接触的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。

kube-scheduler 是 kubernetes 的调度器，它的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个 binding。
K8s scheduler structure

阅读全文 »

发表于 | 分类于 ， ， | | 热度: ℃
字数统计: 4,993 字 | 阅读时长 ≈ 28 分钟

环境介绍

IP Hostname 备注
172.19.170.183 master-1 私有云安装keepalived + haproxy + etcd
172.19.170.184 master-2 私有云安装keepalived + haproxy + etcd
172.19.170.185 master-3 私有云安装keepalived + haproxy + etcd
172.19.170.186 node-1 无
172.19.170.187 node-2 无
172.19.170.100 vip 私有云使用keepalive+haproxy搭建，公有云使用内部负载均衡器

环境初始化

修改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
阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 135 字 | 阅读时长 ≈ 1 分钟

前言

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

ERR_SSL_SERVER_CERT_BAD_FORMAT

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

NET::ERR_CERT_INVALID

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