• 男人公共场合“石更”了怎么办?丨叨可特先生 2019-04-16
  • 老夫到现在也没有明白"人民"究竟为何物。小作出来讲一讲? 2019-04-16
  • (原创)穿救生衣应成赛龙舟的标配 2019-04-07
  • 2018高考今日鸣锣 分享作家们的高考故事:莫言曾说它"很坏" 2019-04-07
  • 618史上最壕“买家”现身 Google以 5.5亿美元投资京东 2019-04-01
  • 一语惊坛(6月12日):五大福利惠及大民生,上合青岛峰会与你我息息相关! 2019-04-01
  • 电视剧抱团出海 又有哪些作品走出了国门 2019-04-01
  • 印度亮出底牌武器威慑中国,解放军应对手段相当硬气:中国不怕 2019-03-30
  • 养老投资:适合的才是最好的 2019-03-30
  • 阳煤投入10.5亿打造“碧水蓝天” 2019-03-30
  • 特朗普所言克里米亚是俄罗斯的和出尔反尔对中国500亿美元商品宣布开征巨额关税,此两点已形成了鲜明的对比,从而充分的暴露了美国真实的战略意图。(原创首发) 2019-03-30
  • 这个世界互联融通的途径很多,不仅有世界杯,还有酒世界杯 五粮液 2019-03-29
  • 拉萨市墨竹工卡县全力打造“绿色矿山” 2019-03-29
  • 地价10年暴涨4倍背后:供地减半 开发商拿地疯狂 ——凤凰网房产上海 2019-03-26
  • 地方党政领导干部安全生产责任制规定出台 2019-03-26
  • 神奇公式秒杀全国11选5 www.bjux.net Kubernetes in action (deployed)

    1. 神奇公式秒杀全国11选5>
    2. 博客>
    3. 正文

    Kubernetes in action (deployed)

    江措小朋友 2019-03-16 23:05:04 浏览474 评论0

    摘要: 一、写在前面: 云提供了kubernetes的Paas服务,但是很多同学对kubernetes的使用不是很清楚,最根本的原因就是出发点不同。cloud是要把技术门槛降低,通过可视化的配置降低学习成本;而企业要的是稳定性,以及故障恢复的时效性,以及故障复盘;这就造成了一系列的问题:support视角:1.

    一、写在前面:

    云提供了kubernetes的Paas服务,但是很多同学对kubernetes的使用不是很清楚,最根本的原因就是出发点不同。cloud是要把技术门槛降低,通过可视化的配置降低学习成本;而企业要的是稳定性,以及故障恢复的时效性,以及故障复盘;这就造成了一系列的问题:
    support视角:1.cloud的support 不知道客户做了什么 操作了什么从而陷入trouble
    user视角 : 2.只要出问题就是cloud的问题
    所以要根本的解决这个问题只能依赖我们不断的了解kubernetes、熟悉kubernetes、kubernetes是一个庞大的生态,很难有人对这个生态圈的每一个组件、每一种解决方案都了如指掌,通过一个现象或者一段报错日志就能定位出问题,并且给一个复盘报告。
    前面写运维 是对传统架构做了一种梳理,以及常用的软件做了一个梳理。
    而kubernetes提供一个一套新的Linux使用思想,就像当年从物理机到虚拟机的变革一样。我觉得kubernetes直接跑在物理机上也未尝不可,反而是一种更好的方案,因为可以减小一层虚拟化的开销。比如一个10台机器的机柜,每台32核128G 那么我们就有320核、1280G的内存可以用,对于小型公司的话业务场景很难利用到该资源池水位的50%-70%的。

    二、Cloud Kubernetes VS private kubernetes

    云端的kubernetes致力于打造一个Paas平台,从阿里云的产品迭代就知道了,是为了meet cloud native的路线的。目前阿里云有几个版本的kubernetes平台:
    1.kubernetes: 3master HA+N(n>1)worker集群
    特点:组件自由可控
    成本:多出3台HA master的钱

    2.kubernetes托管版:0master +N(n>1)worker集群
    特点:组件不可控,master托管在阿里云,丧失了很多扩展的可能性
    成本:节约掉了3台HA master

    3.多可用区kubernetes
    特点:节点可以分布多可用区,避免IOHANG造成某可用区瘫痪 导致可用区故障
    成本:与普通kubernetes版没有太多差异

    4.serverless版
    特点 : 弱化了服务器的概念,基础资源从ECS变成了交付的ECI实例,按量选取
    成本:低,资源用多少给多少钱,也易于扩展,是理想中的主流,实际上不可控因素太多

    而自建的kubernetes自由度很大,可以使用社区的任何插件,甚至阿里云提供的插件也可以使用,所以如果有运维能力的话,这种集群是最适合应用于生产的。目前有个小问题就是阿里云不支持vip,所以如果要自建ha-master的话有点麻烦,因为自建master-ha实际上是在每个master上装haproxy结合keepalived来实现的,部署的yaml模板里面的master节点ip实际上是ha提供的vip。
    所以要自己部署ha集群的话,目前只能使用阿里云的lb,通过阿里云负载均衡代理进来。
    所以考虑到这种场景,如果没有时间瞎折腾的话还是使用阿里云的集群比较好。写这个连载就是想通过对比,让大家更好的理解kubernetes,也是自己的一个学习过程,同时希望能对大家的技术选型能有所帮助。

    三、kubeadm部署kubernetes 1.13.1集群

    为了贴近阿里云当前发布最新版本,选用了1.13而非最新的1.14kubernetes集群

    1.资源规划:

    主机名 IP地址 角色 组件 配置
    k8s-master 192.168.0.242 master kube-apiserver kube-controller-manager kube-scheduler kube-proxy etcd coredns kube-flannel 2C 4G
    k8s-node1 192.168.0.243 worker kube-proxy kube-flannel 2C 4G
    k8s-node2 192.168.0.244 worker kube-proxy kube-flannel 2C 4G
    k8s-node3 192.168.0.245 worker kube-proxy kube-flannel 2C 4G

    2.基本配置:

    docker的安装 : Kubernetes默认的容器运行时仍然是Docker,使用的是kubelet中内置dockershim CRI实现。需要注意的是,Kubernetes 1.13最低支持的Docker版本是1.11.1,最高支持是18.06,而Docker最新版本已经是18.09了,故我们安装时需要指定版本为18.06.1-ce。

    一键安装:
    $ curl -sSL https://raw.githubusercontent.com/willzhang/shell/master/install_docker.sh | sh

    修改主机名:

    #master节点:
    hostnamectl set-hostname k8s-master
    #node1节点:
    hostnamectl set-hostname k8s-node1
    #node2节点:
    hostnamectl set-hostname k8s-node2
    #node3节点:
    hostnamectl set-hostname k8s-node3
    cat >> /etc/hosts << EOF
    192.168.0.242 k8s-master
    192.168.0.243 k8s-node1
    192.168.0.244 k8s-node2
    192.168.0.245 k8s-node2
    EOF
    #关闭防火墙和selinux  默认是关闭的 阿里云主机可以跳过这步
    systemctl stop firewalld && systemctl disable firewalld
    sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config && setenforce 0
    
    #关闭swap  默认也是关闭的  阿里云主机跳过这一步
    swapoff -a
    yes | cp /etc/fstab /etc/fstab_bak
    cat /etc/fstab_bak |grep -v swap > /etc/fstab

    配置时间同步
    使用chrony同步时间,配置master节点与网络NTP服务器同步时间,所有node节点与master节点同步时间。
    master:

    #安装chrony:
    yum install -y chrony
    #注释默认ntp服务器
    sed -i 's/^server/#&/' /etc/chrony.conf
    #指定上游公共 ntp 服务器,并允许其他节点同步时间
    cat >> /etc/chrony.conf << EOF
    server 0.asia.pool.ntp.org iburst
    server 1.asia.pool.ntp.org iburst
    server 2.asia.pool.ntp.org iburst
    server 3.asia.pool.ntp.org iburst
    allow all
    EOF
    #重启chronyd服务并设为开机启动:
    systemctl enable chronyd && systemctl restart chronyd
    #开启网络时间同步功能
    timedatectl set-ntp true
     

    worker:

    #安装chrony:
    yum install -y chrony
    #注释默认服务器
    sed -i 's/^server/#&/' /etc/chrony.conf
    #指定内网 master节点为上游NTP服务器
    echo server 192.168.0.242 iburst >> /etc/chrony.conf
    #重启服务并设为开机启动:
    systemctl enable chronyd && systemctl restart chronyd
    验证
    [[email protected] ~]# chronyc sources
    210 Number of sources = 1
    MS Name/IP address         Stratum Poll Reach LastRx Last sample               
    ===============================================================================
    ^* k8s-master                    2   6    17    35  -4000ns[  -38us] +/-   39ms
    查看存在以^*开头的行,说明已经与服务器时间同步

    修改iptables相关参数
    RHEL / CentOS 7上的一些用户报告了由于iptables被绕过而导致流量路由不正确的问题。创建/etc/sysctl.d/k8s.conf文件,添加如下内容:

    cat <<EOF >  /etc/sysctl.d/k8s.conf
    vm.swappiness = 0
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    net.ipv4.ip_forward = 1
    EOF
    
    # 使配置生效
    modprobe br_netfilter
    sysctl -p /etc/sysctl.d/k8s.conf
     

    加载ipvs相关???br>由于ipvs已经加入到了内核的主干,所以为kube-proxy开启ipvs的前提需要加载以下的内核??椋?br>在所有的Kubernetes节点执行以下脚本:

    cat > /etc/sysconfig/modules/ipvs.modules <<EOF
    #!/bin/bash
    modprobe -- ip_vs
    modprobe -- ip_vs_rr
    modprobe -- ip_vs_wrr
    modprobe -- ip_vs_sh
    modprobe -- nf_conntrack_ipv4
    EOF
    
    #执行脚本
    chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4
    

    上面脚本创建了/etc/sysconfig/modules/ipvs.modules文件,保证在节点重启后能自动加载所需???。 使用lsmod | grep -e ip_vs -e nf_conntrack_ipv4命令查看是否已经正确加载所需的内核???。
    接下来还需要确保各个节点上已经安装了ipset软件包。 为了便于查看ipvs的代理规则,最好安装一下管理工具ipvsadm。

    # yum install ipset ipvsadm -y

    安装kubeadm、kubelet、kubectl
    官方安装文档可以参考:
    https://kubernetes.io/docs/setup/independent/install-kubeadm/

    kubelet 在群集中所有节点上运行的核心组件, 用来执行如启动pods和containers等操作。
    kubeadm 引导启动k8s集群的命令行工具,用于初始化 Cluster。
    kubectl 是 Kubernetes 命令行工具。通过 kubectl 可以部署和管理应用,查看各种资源,创建、删除和更新各种组件

    #配置kubernetes.repo的源,由于官方源国内无法访问,这里使用阿里云yum源
    cat <<EOF > /etc/yum.repos.d/kubernetes.repo
    [kubernetes]
    name=Kubernetes
    baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
    EOF
    
    #在所有节点上安装指定版本 kubelet、kubeadm 和 kubectl
    yum install -y kubelet-1.13.1 kubeadm-1.13.1 kubectl-1.13.1
    
    #启动kubelet服务
    systemctl enable kubelet && systemctl start kubelet
     

    3.master配置

    完整的官方文档可以参考:
    https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/
    https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/

    kubeadm init \
        --apiserver-advertise-address= 192.168.0.242 \
        --image-repository registry.aliyuncs.com/google_containers \
        --kubernetes-version v1.13.1 \
        --pod-network-cidr=10.244.0.0/16
     

    说明一下:这里pod的cidr网段不要和vpc重合 否则会导致流量转发异常 这也就是weish为啥阿里云建集群有地址判断的原因了

    初始化命令:

    --apiserver-advertise-address
    

    指明用 Master 的哪个 interface 与 Cluster 的其他节点通信。如果 Master 有多个 interface,建议明确指定,如果不指定,kubeadm 会自动选择有默认网关的 interface。

    --pod-network-cidr

    指定 Pod 网络的范围。Kubernetes 支持多种网络方案,而且不同网络方案对 --pod-network-cidr 有自己的要求,这里设置为 10.244.0.0/16 是因为我们将使用 flannel 网络方案,必须设置成这个 CIDR。

    --image-repository

    Kubenetes默认Registries地址是 k8s.gcr.io,在国内并不能访问 gcr.io,在1.13版本中我们可以增加–image-repository参数,默认值是 k8s.gcr.io,将其指定为阿里云镜像地址:registry.aliyuncs.com/google_containers。
     

    --kubernetes-version=v1.13.1

    
    关闭版本探测,因为它的默认值是stable-1,会导致从https://dl.k8s.io/release/stable-1.txt下载最新的版本号,我们可以将其指定为固定版本(最新版:v1.13.1)来跳过网络请求 ```
    
     
    [[email protected] ~]# kubeadm init \
    >     --apiserver-advertise-address= 192.168.0.242 \
    >     --image-repository registry.aliyuncs.com/google_containers \
    >     --kubernetes-version v1.13.1 \
    >     --pod-network-cidr=10.244.0.0/16
    [init] Using Kubernetes version: v1.13.1
    [preflight] Running pre-flight checks
        [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.3. Latest validated version: 18.06
    [preflight] Pulling images required for setting up a Kubernetes cluster
    [preflight] This might take a minute or two, depending on the speed of your internet connection
    [preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
    
    [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [kubelet-start] Activating the kubelet service
    [certs] Using certificateDir folder "/etc/kubernetes/pki"
    [certs] Generating "front-proxy-ca" certificate and key
    [certs] Generating "front-proxy-client" certificate and key
    [certs] Generating "etcd/ca" certificate and key
    [certs] Generating "etcd/healthcheck-client" certificate and key
    [certs] Generating "etcd/server" certificate and key
    [certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.0.242 127.0.0.1 ::1]
    [certs] Generating "etcd/peer" certificate and key
    [certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.0.242 127.0.0.1 ::1]
    [certs] Generating "apiserver-etcd-client" certificate and key
    [certs] Generating "ca" certificate and key
    [certs] Generating "apiserver" certificate and key
    [certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.242]
    [certs] Generating "apiserver-kubelet-client" certificate and key
    [certs] Generating "sa" key and public key
    [kubeconfig] Using kubeconfig folder "/etc/kubernetes"
    [kubeconfig] Writing "admin.conf" kubeconfig file
    [kubeconfig] Writing "kubelet.conf" kubeconfig file
    [kubeconfig] Writing "controller-manager.conf" kubeconfig file
    [kubeconfig] Writing "scheduler.conf" kubeconfig file
    [control-plane] Using manifest folder "/etc/kubernetes/manifests"
    [control-plane] Creating static Pod manifest for "kube-apiserver"
    [control-plane] Creating static Pod manifest for "kube-controller-manager"
    [control-plane] Creating static Pod manifest for "kube-scheduler"
    [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
    [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
    [apiclient] All control plane components are healthy after 20.003958 seconds
    [uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
    [kubelet] Creating a ConfigMap "kubelet-config-1.13" in namespace kube-system with the configuration for the kubelets in the cluster
    [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master" as an annotation
    [mark-control-plane] Marking the node k8s-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
    [mark-control-plane] Marking the node k8s-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
    [bootstrap-token] Using token: 86krb1.txcuqz85bgko2xup
    [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
    [bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
    [bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
    [bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
    [bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
    [addons] Applied essential addon: CoreDNS
    [addons] Applied essential addon: kube-proxy
    
    Your Kubernetes master has initialized successfully!
    
    To start using your cluster, you need to run the following as a regular user:
    
      mkdir -p $HOME/.kube
      sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
      sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    You should now deploy a pod network to the cluster.
    Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
      https://kubernetes.io/docs/concepts/cluster-administration/addons/
    
    You can now join any number of machines by running the following on each node
    as root:
    
      kubeadm join 192.168.0.242:6443 --token 86krb1.txcuqz85bgko2xup --discovery-token-ca-cert-hash sha256:87ddcfa1adec67772a33d58bcdaba3cb07c859a25b7d891422f29bd79f9d9b85

    plus:至此 kubernetes的部署变的跟swarm一样简单了,node节点只需要获得token就阔以加入到master

    初始化过程说明:

    [preflight] kubeadm 执行初始化前的检查。
    [kubelet-start] 生成kubelet的配置文件”/var/lib/kubelet/config.yaml”
    [certificates] 生成相关的各种token和证书
    [kubeconfig] 生成 KubeConfig 文件,kubelet 需要这个文件与 Master 通信
    [control-plane] 安装 Master 组件,会从指定的 Registry 下载组件的 Docker 镜像。
    [bootstraptoken] 生成token记录下来,后边使用kubeadm join往集群中添加节点时会用到
    [addons] 安装附加组件 kube-proxy 和 kube-dns。
    Kubernetes Master 初始化成功,提示如何配置常规用户使用kubectl访问集群。
    提示如何安装 Pod 网络。
    提示如何注册其他节点到 Cluster。

    image

    配置 kubectl

    kubectl 是管理 Kubernetes Cluster 的命令行工具,前面我们已经在所有的节点安装了 kubectl。Master 初始化完成后需要做一些配置工作,然后 kubectl 就能使用了。
    依照 kubeadm init 输出的最后提示,推荐用 Linux 普通用户执行 kubectl。

     #创建普通用户并设置密码123456
    useradd centos && echo "centos:123456" | chpasswd centos
    
    #追加sudo权限,并配置sudo免密
    sed -i '/^root/a\centos  ALL=(ALL)       NOPASSWD:ALL' /etc/sudoers
    
    #保存集群安全配置文件到当前用户.kube目录
    su - centos
    mkdir -p $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    #启用 kubectl 命令自动补全功能(注销重新登录生效)
    echo "source <(kubectl completion bash)" >> ~/.bashrc

    需要这些配置命令的原因是:Kubernetes 集群默认需要加密方式访问。所以,这几条命令,就是将刚刚部署生成的 Kubernetes 集群的安全配置文件,保存到当前用户的.kube 目录下,kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。
    如果不这么做的话,我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。
    配置完成后centos用户就可以使用 kubectl 命令管理集群了。
    image

    image
    通过 kubectl describe 指令的输出,我们可以看到 NodeNotReady 的原因在于,我们尚未部署任何网络插件,kube-proxy等组件还处于starting状态。
    另外,我们还可以通过 kubectl 检查这个节点上各个系统 Pod 的状态,其中,kube-system 是 Kubernetes 项目预留的系统 Pod 的工作空间(Namepsace,注意它并不是 Linux Namespace,它只是 Kubernetes 划分不同工作空间的单位):
    可以看到,CoreDNS依赖于网络的 Pod 都处于 Pending 状态,即调度失败。这当然是符合预期的:因为这个 Master 节点的网络尚未就绪。
    集群初始化如果遇到问题,可以使用kubeadm reset命令进行清理然后重新执行初始化。

    部署网络插件
    要让 Kubernetes Cluster 能够工作,必须安装 Pod 网络,否则 Pod 之间无法通信。
    Kubernetes 支持多种网络方案,这里我们使用 flannel
    执行如下命令部署 flannel:
    kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
    image

    可以看到,所有的系统 Pod 都成功启动了,而刚刚部署的flannel网络插件则在 kube-system 下面新建了一个名叫kube-flannel-ds-amd64-lkf2f的 Pod,一般来说,这些 Pod 就是容器网络插件在每个节点上的控制组件。
    Kubernetes 支持容器网络插件,使用的是一个名叫 CNI 的通用接口,它也是当前容器网络的事实标准,市面上的所有容器网络开源项目都可以通过 CNI 接入 Kubernetes,比如 Flannel、Calico、Canal、Romana 等等,它们的部署方式也都是类似的“一键部署”。
    再次查看master节点状态已经为ready状态:
    至此,Kubernetes 的 Master 节点就部署完成了。如果你只需要一个单节点的 Kubernetes,现在你就可以使用了。不过,在默认情况下,Kubernetes 的 Master 节点是不能运行用户 Pod 的。

    4.worker配置

    获取master的token

    [[email protected] kubernetes]# kubeadm token create --print-join-command
    kubeadm join 192.168.0.242:6443 --token 3bpx58.px0vceawb0bjpfeq --discovery-token-ca-cert-hash sha256:87ddcfa1adec67772a33d58bcdaba3cb07c859a25b7d891422f29bd79f9d9b85

    所有节点依次执行
    image
    验证:

    [[email protected] kubernetes]$ kubectl get nodes
    NAME         STATUS   ROLES    AGE   VERSION
    k8s-master   Ready    master   52m   v1.13.1
    k8s-node1    Ready    <none>   46s   v1.13.1
    k8s-node2    Ready    <none>   26s   v1.13.1
    k8s-node3    Ready    <none>   24s   v1.13.1

    nodes状态全部为ready,由于每个节点都需要启动若干组件,如果node节点的状态是 NotReady,可以查看所有节点pod状态,确保所有pod成功拉取到镜像并处于running状态:
    现在把kubeconfig拷贝到各node上验证:
    image
    这时,所有的节点都已经 Ready,Kubernetes Cluster 创建成功,一切准备就绪。
    如果pod状态为Pending、ContainerCreating、ImagePullBackOff 都表明 Pod 没有就绪,Running 才是就绪状态。
    如果有pod提示Init:ImagePullBackOff,说明这个pod的镜像在对应节点上拉取失败,我们可以通过 kubectl describe pod 查看 Pod 具体情况,以确认拉取失败的镜像:
    这里看最后events输出内容,可以看到在下载 image 时失败,如果网络质量不好,这种情况是很常见的。我们可以耐心等待,因为 Kubernetes 会重试,我们也可以自己手工执行 docker pull 去下载这个镜像。

    [[email protected] ~]# docker pull quay.io/coreos/flannel:v0.10.0-amd64
    v0.10.0-amd64: Pulling from coreos/flannel
    ff3a5c916c92: Already exists
    8a8433d1d437: Already exists
    306dc0ee491a: Already exists
    856cbd0b7b9c: Already exists
    af6d1e4decc6: Already exists
    Digest: sha256:88f2b4d96fae34bfff3d46293f7f18d1f9f3ca026b4a4d288f28347fcb6580ac
    Status: Image is up to date for quay.io/coreos/flannel:v0.10.0-amd64
    [[email protected] ~]#

    如果无法从 quay.io/coreos/flannel:v0.10.0-amd64 下载镜像,可以从阿里云或者dockerhub镜像仓库下载,然后改回原来的tag即可:

    docker pull registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64
    docker tag registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64 quay.io/coreos/flannel:v0.10.0-amd64
    docker rmi registry.cn-hangzhou.aliyuncs.com/kubernetes_containers/flannel:v0.10.0-amd64
    

    查看master的镜像:
    image

    查看node节点下载了哪些镜像:
    image

    至此,一个1master+3worker的集群就部署完毕了,下面就是测试各个组件了
    Plus:集群证书1年为周期,如果集群超过了1年的话需要重新更新证书,证书过期不影响集群功能,但是kubectl无法连接到apiserver

    四、kubernetes集群体验

    参考文档:
    https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

    如果有docker使用基础的同学这里就很简单了,说到底,kubernetes是对docker的能力扩展?;叵氲笔迸艿谝桓鋈萜魇鞘裁茨??docker run吧,同理,kuernetes也可以通过kubectl来管理;而当时docker是怎么实现容器编排的呢?docker-compose吧,同理,kubernetes其实也就是一个编排工具,可以利用yaml文件结合kubernetes的能力标签 apply -f 出一个完美的应用;说到kubernetes是compose的扩展,是因为他有更强大的能力,比如流量管理、服务管理、租户隔离等等。

    1.创建一个nginx deployment扩容2个nginx

    image

    image
    image
    我们都知道无论pod ip还是service ip 都是一个集群内的vip,是一个集群内的概念,只能在集群内才能访问到。
    那么我们如何才能在公网能访问到呢?这个就需要我们通过kubeproxy把端口映射到节点

    [[email protected] ~]$ kubectl expose deployment nginx --port=80 --type=NodePort
    service/nginx exposed
    [[email protected] ~]$ kubectl get services nginx
    NAME    TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
    nginx   NodePort   10.98.9.151   <none>        80:30699/TCP   15s
    

    image
    访问的生命周期:
    1.我们在创建pod的时候在node1 ,node3 上起了2个replicas 这是随机的 scheduler优选之后产生的部署节点
    2.集群内有2个vip,把请求转发到pod里面 telnet 10.244.1.2 80 是通的 其实这就是flannel cni产生的网络端点
    image
    这个端点是我们刚才创建集群时候指定cni网段产生的 --pod-network-cidr=10.244.0.0/16
    随着pod的增多 会逐渐把网段耗尽,所以最开始的时候一定要规划好集群规模
    3.kubeproxy映射,把flannel虚拟网络的地址和宿主机地址映射 在每个节点上启动一个node port 映射到集群内部
    这也就是为啥node 2并没有分配到pod 但是端口是通的的原因
    4.最后通过node的端口来访问服务,node可以通过阿里云的lb组件映射到负载均衡上,阿里云就是这么做的。如果是自己的话,那么就建个nginx转发吧,或者手工绑定slb或者sdk绑定 都OK。
    5.正常的访问:
    slb:80-->nodeport:30699-->flannel cni:80-->container inner port
    image

    dns验证:

     kubectl run -it curl --image=radial/busyboxplus:curl

    image
    通过pod ip(cni)访问 也没有问题
    image

    Pod调度到Master节点
    出于安全考虑,默认配置下Kubernetes不会将Pod调度到Master节点。查看Taints字段默认配置:
    默认是污点节点 pod无法创建
    image
    解除污点,允许业务容器pod调度

    kubectl taint node k8s-master node-role.kubernetes.io/master-

    image
    由于是单节点的,我怕把master搞挂了,还是恢复unschedule吧

    kubectl taint node k8s-master node-role.kubernetes.io/master=:NoSchedule
    

    kube-proxy开启ipvs
    image

    [[email protected] ~]$  kubectl edit cm kube-proxy -n kube-system
    configmap/kube-proxy edited
    

    什么是IPVS?
    IPVS (IP Virtual Server,IP虚拟服务器)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术,通常称为第4层LAN交换。

    IPVS集成在LVS(Linux Virtual Server)中,它在主机中运行,并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器,并使真实服务器的服务在单个IP地址上显示为虚拟服务。因此IPVS天然支持Kubernetes Service。

    为什么选择IPVS
    随着kubernetes使用量的增长,其资源的可扩展性变得越来越重要。特别是对于使用kubernetes运行大型工作负载的开发人员或者公司来说,service的可扩展性至关重要。

    kube-proxy是为service构建路由规则的???,之前依赖iptables来实现主要service类型的支持,比如(ClusterIP和NodePort)。但是iptables很难支持上万级的service,因为iptables纯粹是为防火墙而设计的,并且底层数据结构是内核规则的列表。

    kubernetes早在1.6版本就已经有能力支持5000多节点,这样基于iptables的kube-proxy就成为集群扩容到5000节点的瓶颈。举例来说,如果在一个5000节点的集群,我们创建2000个service,并且每个service有10个pod,那么我们就会在每个节点上有至少20000条iptables规则,这会导致内核非常繁忙。

    基于IPVS的集群内负载均衡就可以完美的解决这个问题。IPVS是专门为负载均衡设计的,并且底层使用哈希表这种非常高效的数据结构,几乎可以允许无限扩容。

    IPVS vs. IPTABLES区别
    IPVS模式在Kubernetes v1.8中引入,并在v1.9中进入了beta。 1.11中实现了GA(General Availability)。IPTABLES模式在v1.1中添加,并成为自v1.2以来的默认操作模式。 IPVS和IPTABLES都基于netfilter。 IPVS模式和IPTABLES模式之间的差异如下:

    IPVS为大型集群提供了更好的可扩展性和性能。
    IPVS支持比iptables更复杂的负载平衡算法(最小负载,最少连接,位置,加权等)。
    IPVS支持服务器健康检查和连接重试等。
    image

    移除节点和集群
    kubernetes集群移除节点
    以移除k8s-node2节点为例,在Master节点上运行:
    kubectl drain k8s-node2 --delete-local-data --force --ignore-daemonsets
    kubectl delete node k8s-node2
    上面两条命令执行完成后,在k8s-node2节点执行清理命令,重置kubeadm的安装状态:
    kubeadm reset
    在master上删除node并不会清理k8s-node2运行的容器,需要在删除节点上面手动运行清理命令。
    如果你想重新配置集群,使用新的参数重新运行kubeadm init或者kubeadm join即可。

    【云栖快讯】阿里巴巴小程序繁星计划,20亿补贴第一弹云应用免费申请,限量从速!  详情请点击

    网友评论

  • 男人公共场合“石更”了怎么办?丨叨可特先生 2019-04-16
  • 老夫到现在也没有明白"人民"究竟为何物。小作出来讲一讲? 2019-04-16
  • (原创)穿救生衣应成赛龙舟的标配 2019-04-07
  • 2018高考今日鸣锣 分享作家们的高考故事:莫言曾说它"很坏" 2019-04-07
  • 618史上最壕“买家”现身 Google以 5.5亿美元投资京东 2019-04-01
  • 一语惊坛(6月12日):五大福利惠及大民生,上合青岛峰会与你我息息相关! 2019-04-01
  • 电视剧抱团出海 又有哪些作品走出了国门 2019-04-01
  • 印度亮出底牌武器威慑中国,解放军应对手段相当硬气:中国不怕 2019-03-30
  • 养老投资:适合的才是最好的 2019-03-30
  • 阳煤投入10.5亿打造“碧水蓝天” 2019-03-30
  • 特朗普所言克里米亚是俄罗斯的和出尔反尔对中国500亿美元商品宣布开征巨额关税,此两点已形成了鲜明的对比,从而充分的暴露了美国真实的战略意图。(原创首发) 2019-03-30
  • 这个世界互联融通的途径很多,不仅有世界杯,还有酒世界杯 五粮液 2019-03-29
  • 拉萨市墨竹工卡县全力打造“绿色矿山” 2019-03-29
  • 地价10年暴涨4倍背后:供地减半 开发商拿地疯狂 ——凤凰网房产上海 2019-03-26
  • 地方党政领导干部安全生产责任制规定出台 2019-03-26