【云原生Kubernetes】二进制搭建Kubernetes集群(中)——部署node节点(2)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
云解析DNS,个人版 1个月
简介: 上一篇中已部署了etcd分布式数据库、master01节点,本文将部署Kubernetes集群中的 worker node 节点和 CNI 网络插件。

附录3:proxy.sh

#!/bin/bash
 #example:proxy.sh 192.168.41.42
 #脚本后跟的位置参数1是node节点的IP地址。
 NODE_ADDRESS=$1
 #创建 kube-proxy 启动参数配置文件
 cat >/opt/kubernetes/cfg/kube-proxy <<EOF
 KUBE_PROXY_OPTS="--logtostderr=true \
 --v=4 \
 --hostname-override=${NODE_ADDRESS} \
 --cluster-cidr=172.17.0.0/16 \
 --proxy-mode=ipvs \
 --kubeconfig=/opt/kubernetes/cfg/kube-proxy.kubeconfig"
 EOF
 #--hostnameOverride: 参数值必须与 kubelet 的值一致,否则 kube-proxy 启动后会找>不到该 Node,从而不会创建任何 ipvs 规则
 #--cluster-cidr:指定 Pod 网络使用的聚合网段,Pod 使用的网段和 apiserver 中指定的 service 的 cluster ip 网段不是同一个网段。 kube-proxy 根据 --cluster-cidr 判断集群内部和外部流量,指定 --cluster-cidr 选项后 kube-proxy 才会对访问 Service IP 的请求做 SNAT,即来自非 Pod 网络的流量被当成外部流量,访问 Service 时需要做 SNAT。
 #--proxy-mode:指定流量调度模式为ipvs模式,可添加--ipvs-scheduler选项指定ipvs调度算法(rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq)
 #--kubeconfig: 指定连接 apiserver 的 kubeconfig 文件
 #----------------------
 #创建 kube-proxy.service 服务管理文件
 cat >/usr/lib/systemd/system/kube-proxy.service <<EOF
 [Unit]
 Description=Kubernetes Proxy
 After=network.target
 [Service]
 EnvironmentFile=-/opt/kubernetes/cfg/kube-proxy
 ExecStart=/opt/kubernetes/bin/kube-proxy $KUBE_PROXY_OPTS
 Restart=on-failure
 [Install]
 WantedBy=multi-user.target
 EOF
 systemctl daemon-reload
 systemctl enable kube-proxy
 systemctl restart kube-proxy
复制代码


4.3 部署网络组件

网络插件主要两种:Flannel、Calico。安装其中任意一个即可。

我们这里使用方法二,安装Calico网络插件。

方法一:部署Flannel

#--------------在 node01 节点上操作---------------
 #上传 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
 cd /opt/
 docker load -i flannel.tar
 docker images
 #解压
 mkdir /opt/cni/bin
 tar zxvf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
 #传给node02节点
 scp cni/ flannel.tar root@192.168.41.43:/root/
 docker load -i flannel.tar
 #---------------在 master01 节点上操作-----------------
 #上传 kube-flannel.yml 文件到 /opt/k8s 目录中,部署 CNI 网络
 cd /opt/k8s
 kubectl apply -f kube-flannel.yml 
 kubectl get pods -n kube-system
 NAME                    READY   STATUS    RESTARTS   AGE
 kube-flannel-ds-hjtc7   1/1     Running   0          7s
 kubectl get nodes
 NAME            STATUS   ROLES    AGE   VERSION
 192.168.41.42   Ready    <none>   81m   v1.20.11
复制代码


方法二:部署 Calico

#--------------------在 master01 节点上操作---------------------------------
 #calico.yaml 文件可以直接从网上获取,使用wget下载即可
 #上传 calico.yaml 文件到 /opt/k8s 目录中,部署 CNI 网络
 cd /opt/k8s
 vim calico.yaml
 #修改里面定义Pod网络(CALICO_IPV4POOL_CIDR),要与前面kube-controller-manager配置文件指定的cluster-cidr网段一致
     - name: CALICO_IPV4POOL_CIDR
       value: "10.244.0.0/16"    #默认是192.168.0.0/16,需要改成和kube-controller-manager配置文件指定的cluster-cidr网段一致
 #通过calico.yaml资源清单,使用kubectl apply创建pod,-f指定清单文件
 kubectl apply -f calico.yaml
 #等待1~2分钟,查看pod状态,-n指定命名空间,默认是default命名空间。都是Running状态就OK了。
 kubectl get pods -n kube-system
 NAME                                       READY   STATUS    RESTARTS   AGE
 calico-kube-controllers-659bd7879c-gq5fb   1/1     Running   0          2m53s
 calico-node-dd4gc                          1/1     Running   0          2m53s
 calico-node-rg299                          1/1     Running   0          2m53s
 #再次查看集群的节点信息,都是Ready状态。
 #等 Calico Pod 都 Running,节点也会准备就绪
 kubectl get nodes
 NAME            STATUS   ROLES    AGE   VERSION
 192.168.41.42   Ready    <none>   73m   v1.20.11
 192.168.41.43   Ready    <none>   74m   v1.20.11
 #至此,单master节点k8s集群就部署成功了
复制代码


网络异常,图片无法展示
|


网络异常,图片无法展示
|


网络异常,图片无法展示
|


网络异常,图片无法展示
|


4.4 部署 CoreDNS

CoreDNS:可以为集群中的 service 资源创建一个域名与 IP 的对应关系解析。

service发现是k8s中的一个重要机制,其基本功能为:在集群内通过服务名对服务进行访问,即需要完成从服务名到ClusterIP的解析。

k8s主要有两种service发现机制:环境变量和DNS。没有DNS服务的时候,k8s会采用环境变量的形式,但一旦有多个service,环境变量会变复杂,为解决该问题,我们使用DNS服务。

#---------------1、在所有 node 节点上操作-----------------
 #上传 coredns.tar 到 /opt 目录中,之后导入镜像
 cd /opt
 docker load -i coredns.tar
 #---------------2、在 master01 节点上操作-----------------
 #上传 coredns.yaml 文件到 /opt/k8s 目录中,部署 CoreDNS 
 cd /opt/k8s
 #通过coredns.yaml资源清单,使用kubectl apply创建该pod,-f指定清单文件
 kubectl apply -f coredns.yaml
 #等待1~2分钟,查看pod状态,-n指定命名空间,默认是default命名空间。coredns是Running状态就OK了。
 kubectl get pods -n kube-system 
 NAME                              READY   STATUS    RESTARTS   AGE
 coredns-6954c77b9b-r4lc6          1/1     Running   0          5m21s
 #DNS 解析测试
 kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
 If you don't see a command prompt, try pressing enter.
 / # nslookup kubernetes
 Server:    10.0.0.2
 Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
 Name:      kubernetes
 Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
 / #
复制代码


1、在所有 node 节点上操作

网络异常,图片无法展示
|


2、在 master01 节点上操作

网络异常,图片无法展示
|


网络异常,图片无法展示
|


五、CNI网络插件介绍

5.1 Kubernetes的三种网络

网络异常,图片无法展示
|

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2天前
|
存储 JavaScript
DOM 节点列表长度(Node List Length)
名为 &quot;title&quot; 的元素节点,并存储在节点列表 x 中。通过 &quot;length&quot; 属性确定 x 的长度(即 &quot;title&quot; 节点总数)。利用 for 循环遍历整个列表,访问每个 &quot;title&quot; 节点的第一个子节点的值,并将其写入文档。
|
4天前
|
存储 JavaScript
DOM 节点列表长度(Node List Length)
名为 &quot;title&quot; 的元素节点,并存储在节点列表 x 中。通过 &quot;length&quot; 属性确定 x 的长度(即 &quot;title&quot; 节点总数)。利用 for 循环遍历整个列表,访问每个 &quot;title&quot; 节点的第一个子节点的值,并将其写入文档。
|
6天前
|
Kubernetes 容器 Perl
Kubernetes(K8S) Node NotReady 节点资源不足 Pod无法运行
Kubernetes(K8S) Node NotReady 节点资源不足 Pod无法运行
10 0
|
7天前
|
Kubernetes Cloud Native 持续交付
云原生技术浪潮下的微服务架构实践
在数字化转型的今天,云原生技术成为推动企业IT革新的关键力量。本文将通过浅显易懂的语言和实际案例,带领读者了解云原生的核心概念、微服务架构的设计原则以及如何在云平台上高效部署和管理微服务。我们将从基础概念出发,逐步深入到微服务的生命周期管理,探讨如何在云原生生态中实现快速迭代和持续交付。无论你是云原生技术的初学者,还是希望深化理解的开发者,这篇文章都将为你提供有价值的指导和思考。
|
1天前
|
Cloud Native API 云计算
云原生架构:企业数字化转型的催化剂
【8月更文挑战第18天】在数字化浪潮不断推进的今天,云原生技术已成为推动企业IT转型的核心力量。通过深入探讨云原生架构的基本原理、优势以及实施策略,本文旨在为企业提供一个清晰的云原生应用路线图,帮助它们在竞争激烈的市场环境中获得灵活性和创新能力。文章将详细阐述云原生如何助力企业实现资源的最优配置,加速产品上市时间,并提高系统的可维护性和扩展性。
|
2天前
|
运维 Cloud Native 云计算
探索云原生架构的未来趋势与挑战
【8月更文挑战第17天】随着云计算技术的不断发展和成熟,云原生架构已经成为现代软件开发的重要趋势。本文将深入探讨云原生架构的核心概念、优势以及面临的未来挑战和发展趋势,旨在为读者提供一个全面了解云原生架构的窗口,同时展望其对未来软件开发模式的影响。
|
7天前
|
Cloud Native 持续交付 开发者
云原生之旅:从传统到现代的架构演化
本文将通过一次虚拟的旅行,带领读者穿越回过去,探索软件架构的发展脉络。我们将从单体应用开始,一路经过服务化拆分,最终抵达云原生的乐土。这不仅是一段技术演进的历史,也是对如何在不断变化的技术浪潮中保持初心与创新的启示录。
18 2
|
8天前
|
运维 Cloud Native Devops
云原生架构:企业数字化转型的加速器
【8月更文挑战第11天】在数字化浪潮中,企业正经历前所未有的转型压力。云原生架构作为一种新型的IT架构模式,以其灵活性、可扩展性和高效性成为企业应对这一挑战的关键工具。本文将深入探讨云原生架构的核心概念、优势以及它如何助力企业实现敏捷开发、自动化运维和微服务治理,最终加速企业的数字化转型之旅。
20 3
|
10天前
|
运维 Cloud Native 持续交付
云原生技术浪潮下的微服务架构演进
【8月更文挑战第9天】随着云计算技术的不断进步,云原生已成为推动现代软件开发和运维模式变革的关键力量。本文旨在探讨云原生环境下微服务架构的演化路径,分析其在提升应用开发效率、促进持续交付以及增强系统可扩展性方面的优势。文章将着重讨论微服务架构在设计原则、部署策略及治理机制方面的适应性调整,并展望未来云原生技术如何进一步影响微服务架构的创新与实践。
|
7天前
|
运维 Cloud Native 持续交付
云原生时代的微服务架构演进
【8月更文挑战第12天】在数字化转型的浪潮中,企业级应用正逐渐从传统的单体架构向微服务架构转变。本文将探讨微服务架构的概念、优势以及在云原生环境下的演进路径,同时分析微服务实施过程中面临的挑战和解决策略。通过深入讨论微服务与容器化技术的结合,文章旨在为读者提供一种现代化的应用开发和部署范式。