云原生|kubernetes|kubernetes集群部署神器kubekey安装部署高可用k8s集群(半离线形式)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 云原生|kubernetes|kubernetes集群部署神器kubekey安装部署高可用k8s集群(半离线形式)

前言:

前面利用kubekey部署了一个简单的非高可用,etcd单实例的kubernetes集群,经过研究,发现部署过程可以简化,省去了一部分下载过程(主要是下载kubernetes组件的过程)只是kubernetes版本会固定在1.22.16版本,etcd集群可以部署成生产用的外部集群,并且apiserver等等组件也是高可用,并且部署非常简单,因此,也就非常nice了。

一,

离线安装包

####注,该离线包适用于centos7并在centos7下全系列验证通过,欧拉的部分版本应该也可以使用

链接:https://pan.baidu.com/s/1d4YR_a244iZj5aj2DJLU2w?pwd=kkey
提取码:kkey

安装包内大体有如下文件:

第一个没什么好说的,kubekey的安装包,解压后查看是否有执行权限就可以了,如果没有,添加执行权限

第二个是kubernetes组件的二进制文件,直接解压到root目录下就可以了

第三个是强依赖,解压后,进入解压后目录,执行 rpm -ivh *  就可以了,

第四个事部署清单,需要按照 实际的情况填写IP,还有服务器的密码,别的基本不需要动

然后就可以执行部署工作了,只是会拉取一些镜像,这些镜像是从kubesphere官网拉取,如果嫌拉取镜像太慢,可以export KKZONE=cn ,然后镜像都会从阿里云拉取。

二,

部署清单文件的解析

文件内容如下:

主要是hosts标签,roleGroups标签

hosts标签下面,有几个节点写几个节点,我实验的时候是使用了四个VMware虚拟机,每个虚拟机是4G内存,2CPUI的规格,IP地址和密码按实际填写

用户使用的是root,其实也是避免一些失败的情况,毕竟root权限最高嘛,部署安装工作还是不要花里胡哨的用普通用户(yum部署都从来不用普通用户,就是避免失败的嘛)。

roleGroups的标签是11,12,13 这三个节点做主节点,也是etcd集群的节点

高可用使用的haproxy,具体实现细节还没分析出来。

具体的安装部署的日志在/root/kubekey/logs

apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
  name: sample
spec:
  hosts:
  - {name: node1, address: 192.168.123.11, internalAddress: 192.168.123.11, user: root, password: "密码"}
  - {name: node2, address: 192.168.123.12, internalAddress: 192.168.123.12, user: root, password: "密码"}
  - {name: node3, address: 192.168.123.13, internalAddress: 192.168.123.13, user: root, password: "密码"}
  - {name: node4, address: 192.168.123.14, internalAddress: 192.168.123.14, user: root, password: "密码"}
  roleGroups:
    etcd:
    - node1
    - node2
    - node3
    control-plane: 
    - node1
    - node2
    - node3
    worker:
    - node4
  controlPlaneEndpoint:
    ## Internal loadbalancer for apiservers 
    internalLoadbalancer: haproxy
    domain: lb.kubesphere.local
    address: ""
    port: 6443
  kubernetes:
    version: v1.23.16
    clusterName: cluster.local
    autoRenewCerts: true
    containerManager: docker
  etcd:
    type: kubekey
  network:
    plugin: calico
    kubePodsCIDR: 10.244.0.0/18
    kubeServiceCIDR: 10.96.0.0/18
    ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
    multusCNI:
      enabled: false
  registry:
    privateRegistry: ""
    namespaceOverride: ""
    registryMirrors: []
    insecureRegistries: []
  addons: []

三,

部署完成的状态检查

Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-2               Healthy   {"health":"true"}   
etcd-1               Healthy   {"health":"true"}   
etcd-0               Healthy   {"health":"true"}   
[root@centos1 ~]# kubectl get po -A -owide
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE    IP               NODE    NOMINATED NODE   READINESS GATES
kube-system   calico-kube-controllers-84897d7cdf-hrj4f   1/1     Running   0          152m   10.244.28.2      node3   <none>           <none>
kube-system   calico-node-2m7hp                          1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
kube-system   calico-node-5ztjk                          1/1     Running   0          152m   192.168.123.14   node4   <none>           <none>
kube-system   calico-node-96dmb                          1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   calico-node-rqp2p                          1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   coredns-b7c47bcdc-bbxck                    1/1     Running   0          152m   10.244.28.3      node3   <none>           <none>
kube-system   coredns-b7c47bcdc-qtvhf                    1/1     Running   0          152m   10.244.28.1      node3   <none>           <none>
kube-system   haproxy-node4                              1/1     Running   0          152m   192.168.123.14   node4   <none>           <none>
kube-system   kube-apiserver-node1                       1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
kube-system   kube-apiserver-node2                       1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   kube-apiserver-node3                       1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   kube-controller-manager-node1              1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
kube-system   kube-controller-manager-node2              1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   kube-controller-manager-node3              1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   kube-proxy-649mn                           1/1     Running   0          152m   192.168.123.14   node4   <none>           <none>
kube-system   kube-proxy-7q7ts                           1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   kube-proxy-dmd7v                           1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   kube-proxy-fpb6z                           1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
kube-system   kube-scheduler-node1                       1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
kube-system   kube-scheduler-node2                       1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   kube-scheduler-node3                       1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   nodelocaldns-565pz                         1/1     Running   0          152m   192.168.123.12   node2   <none>           <none>
kube-system   nodelocaldns-dpwlx                         1/1     Running   0          152m   192.168.123.13   node3   <none>           <none>
kube-system   nodelocaldns-ndlbw                         1/1     Running   0          152m   192.168.123.14   node4   <none>           <none>
kube-system   nodelocaldns-r8gjl                         1/1     Running   0          152m   192.168.123.11   node1   <none>           <none>
[root@centos1 ~]# kubectl get no -owide
NAME    STATUS   ROLES                  AGE    VERSION    INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
node1   Ready    control-plane,master   152m   v1.23.16   192.168.123.11   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node2   Ready    control-plane,master   152m   v1.23.16   192.168.123.12   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node3   Ready    control-plane,master   152m   v1.23.16   192.168.123.13   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8
node4   Ready    worker                 152m   v1.23.16   192.168.123.14   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://20.10.8

在将12   节点关闭后,可以看到 kubernetes集群仍可以正常运行(11不能关,因为是管理节点嘛,那些集群的config文件没拷贝到其它节点)

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
17 4
|
3天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
21 3
|
3天前
|
监控 Cloud Native 持续交付
云原生技术深度解析:重塑现代应用开发与部署范式####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在现代软件开发中的重要性。通过剖析容器化、微服务架构、持续集成/持续部署(CI/CD)等关键技术,本文旨在揭示云原生技术如何促进应用的敏捷性、可扩展性和高可用性,进而推动企业数字化转型进程。不同于传统摘要仅概述内容要点,本部分将融入具体案例分析,直观展示云原生技术在实际应用中的显著成效与挑战应对策略,为读者提供更加丰富、立体的理解视角。 ####
|
7天前
|
Kubernetes Cloud Native 开发者
云原生技术入门:Kubernetes和Docker的协作之旅
【10月更文挑战第22天】在数字化转型的浪潮中,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,引领读者步入云原生的世界,着重介绍Kubernetes和Docker如何携手打造弹性、可扩展的云环境。我们将从基础概念入手,逐步深入到它们在实际场景中的应用,以及如何简化部署和管理过程。文章不仅为初学者提供入门指南,还为有一定基础的开发者提供实践参考,共同探索云原生技术的无限可能。
18 3
|
6天前
|
运维 Kubernetes Cloud Native
云原生入门:Kubernetes和容器化的未来
【10月更文挑战第23天】本文将带你走进云原生的世界,探索Kubernetes如何成为现代软件部署的心脏。我们将一起揭开容器化技术的神秘面纱,了解它如何改变软件开发和运维的方式。通过实际的代码示例,你将看到理论与实践的结合,感受到云原生技术带来的革命性影响。无论你是初学者还是有经验的开发者,这篇文章都将为你开启一段新的旅程。让我们一起踏上这段探索之旅,解锁云原生技术的力量吧!
|
9天前
|
Kubernetes Cloud Native 持续交付
云端新纪元:云原生技术重塑IT架构####
【10月更文挑战第20天】 本文深入探讨了云原生技术的兴起背景、核心理念、关键技术组件以及它如何引领现代IT架构迈向更高效、灵活与可扩展的新阶段。通过剖析Kubernetes、微服务、Docker等核心技术,本文揭示了云原生架构如何优化资源利用、加速应用开发与部署流程,并促进企业数字化转型的深度实践。 ####
|
8天前
|
监控 Cloud Native Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
52 10
|
1天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
2天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
3天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
12 2

推荐镜像

更多