K8s – Dashboard

这里只介绍如何部署Dashboard,至于使用方法,会在之前的文章:K8s – Core Resource Management Method GUI部分进行总结;

安装部署Dashboard

上传Dashboard的Image

root@f0-15:~# docker pull docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
v1.8.3: Pulling from k8scn/kubernetes-dashboard-amd64
a4026007c47e: Pull complete 
Digest: sha256:ebc993303f8a42c301592639770bd1944d80c88be8036e2d4d0aa116148264ff
Status: Downloaded newer image for k8scn/kubernetes-dashboard-amd64:v1.8.3
docker.io/k8scn/kubernetes-dashboard-amd64:v1.8.3
root@f0-15:~# docker images |grep dashboard
k8scn/kubernetes-dashboard-amd64   v1.8.3                     fcac9aa03fd6   4 years ago   102MB
root@f0-15:~# docker tag fcac9aa03fd6 harbor.frank.com/public/dashboard:v1.8.3
root@f0-15:~# docker push harbor.frank.com/public/dashboard:v1.8.3
完整阅读

简单易用的批处理文件

由于安全原因,实验环境必须跳板机(现有的是Win Server,开启了多账户),从实验环境拷贝东西回来,也需要特定的接口,此时还没有GUI,每次手动调用接口很麻烦,所以就写了一个简单的批处理文件,可以执行如下功能:

  • 拖拽需要上传的文件到这个批处理文件上,可以自动读出该文件的实际路径;
  • 自动读取当前用户名;
  • 执行完后不自动退出,显示输出结果;

下载Curl Win版本

这个必须科学上网才能下载,我直接附在这里,方便下载:

完整阅读

K8s – Traefik-Ingress

coreDNS实现了服务在集群被自动发现,那么如何实现服务在集群被自动发现呢?这里有两种方法,这里只关注Ingress资源:

  • 使用nodeport service,在这种方法中,kube-proxy只能使用iptables模型,不能使用ipvs模型;
  • 使用Ingress资源,只能调度并暴露7层应用,特质http或https;

常用的Ingress控制器主要有以下几种,这里使用traefik:

  • Ingress-nginx
  • HAProxy
  • Traefik

注意:ingress资源和ingress控制器不是一个东西(具体可以看最下面的流程图):

  • ingress资源:专用于暴露7层应用(http/https)到k8s集群外的一种核心资源;
  • ingress控制器:简化版本的nginx(调度流量)+go脚本(动态识别yaml,主要用于监控ingress配置清单的变化以做出应对),traefik就是其中之一;

安装部署Traefik

上传Traefik的Image

完整阅读

K8s – CoreDNS

服务发现

服务之间互相定位的过程,以适应如下服务特点:

  • 动态性强;
  • 更新发布频繁;
  • 支持自动伸缩;

在k8s集群里,pod ip是不断变化的,如何找到对应的pods?首先集群网络抽象了集群IP,Service资源绑定Cluster IP并暴露这个资源,Service本身根据标签选择器,来锁定一组pods,并通过ipvs算法分配这组pods的资源。也可以参考上一篇的总结:管理Service资源

那么新的问题来了,虽然可以通过Service找到pod,但如果有很多不同的Services,很难把所有Services与Customer IP的关系记下来,这个是不是很像DNS被创造出来的初衷^_^~?那我们是否可以通过类似DNS的机制,绑定Service和Cluster IP呢?答案是肯定的:

  • Kube-dns,k8s v1.10之前默认使用;
  • Coredns,k8s v1.11以后默认使用;

安装部署CoreDNS

完整阅读

K8s – CNI Network Component

我看的教程算是2020年初的,所以根据现在的时间,已经过去两年半了,下面的信息不一定很准确,后面如果哪里不正确,随着学习的深入,再更改和说明。CNI的全程是Container Network Interface,主要为了解决Pod资源在不同宿主机之间互通的。

常见CNI组件

所有CNI都部署在node节点;

  • Flannel,19年的市场占有率38%;
  • Calico,19年的市场占有率35%;
  • Canal:结合了flannel和calico;19年的市场占有率5%;
  • Contiv:思科开源的;
  • OpenContrail:Juniper开源的;
  • NSX-T:vmware开源的;
  • Kube-router:试图取代kube-proxy,但使用的不多;

Flannel

安装部署Flannel

可以从Github上直接下载,目前Link在这里:https://github.com/flannel-io/flannel/releases/download/v0.11.0/flannel-v0.11.0-linux-amd64.tar.gz,但国内环境可能不好,所以需要科学上网或者多尝试几次;分别在node13和node14上部署Flannel:

完整阅读
blonde teen swallows load.xxx videos