蓝海大脑水冷工作站具有高性能，高密度、扩展性强等特点。液冷GPU服务器产品支持1~20块 GPU卡，还可以选择。芯片主要采用龙芯、飞腾、申威、海光、英伟达、Intel、AMD。完全定制啊，敲开心。适配多个存储卡，适用于深度学习训练及推理、生命科学、医药研发、虚拟仿真等场景，覆盖服务器、静音工作站、数据中心等多种产品形态，量身定制，满足客户全场景需求。为了能使本地能连接k8s集群更好的测试client-go的功能，我在服务器上为本地签发了kubeconfig文件，放到本地之后出现如下的错误。
通过查阅资料发现了一个kubectl的参数 --insecure-skip-tls-verify ，加上这个参数之后确实好使了，但是，总是感觉治标不治本，所以经过一番查阅是apiserver的证书中没有添加 10855 这个ip导致的，需要重新生成一下证书，具体 *** 作如下：
从上面可以看出ip中并没有报错信息中的 10855 这个IP地址，所以需要重新生成。
为了保险起见，这里选择将证书移动到其他位置。
--apiserver-cert-extra-sans 参数后可以加上需要添加的IP地址，这里为了省事儿一次性添加了多个，具体情况按需添加即可。
通过检查可以看到新的证书已经成了，现在只需要重启apiserver即可。如果出现问题，可以删除新的证书，将老的证书移回原位，重启apiserver即可。
可以看到现在不加参数也不出现报错了，到这里就已经大功告成了。<table style="width:100%">
<tr>
<th width=10%, bgcolor=yellow >主机名</th>
<th width=10%, bgcolor=yellow> *** 作系统</th>
<th width=20%, bgcolor=yellow>IP地址</th>
<th width=15%, bgcolor=yellow>角色</th>
<th width=45%, bgcolor=yellow>安装软件</th>
</tr>
<tr>
<td bgcolor=#eeeeee align="center"> node1 </td>
<td align="center"> CentOS 7 </td>
<td align="center"> 192168192128 </td>
<td align="center"> Master、Node </td>
<td align="left"> etcd、kube-apiserver、kube-scheduler、kube-controller-manager、kubelet、kube-proxy、flannel、docker </td>
</tr>
<tr>
<td bgcolor=#00FF00 align="center">node2 </td>
<td align="center"> CentOS 7 </td>
<td align="center"> 192168192128 </td>
<td align="center"> Node </td>
<td align="left"> etcd、kubelet、kube-proxy、flannel、docker </td>
<tr>
<td bgcolor=rgb(0,10,0) align="center">node3 </td>
<td align="center"> CentOS 7 </td>
<td align="center"> 192168192128 </td>
<td align="center"> Node </td>
<td align="left"> etcd、kubelet、kube-proxy、flannel、docker </td>
</table>
在/usr/lib/systemd/system/下创建kube-apiserverservice
内容如下：
（-iface=eth0注意也要改）
注意：以上这步只需要在kubernetes node集群中的一台执行一次就可以了。
注意1：将配置文件中的IP地址更改为你的每台node节点的IP地址（除了--api-servers=>
本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：
k8s 是经典的一对多模型，有一个主要的管理节点 master 和许多的工作节点 slaver 。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个 docker 容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。
在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。
要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。
k8s 把数量众多的服务器重新抽象为一个统一的资源池 ，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。
接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将 create 及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：
接下来进入正题，首先来了解一下 k8s 中最最最常用的命令 kubectl get ，要记住，k8s 把所有的东西都抽象成了资源，而 kubectl get 就是用来查看这些资源的。最常见的资源就是 pod 。
不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：
-n 参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空间下。
执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：
其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：
kubectl get 可以列出 k8s 中所有资源
这里只介绍了如何用 kubectl 获取 pod 的列表。但是不要把 get 和 pod 绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以 get pod ，还可以 get svc ( 查看服务 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，虽然说 kubectl get pod 是最常用的一个，但是如果想查看某个资源而又不知道命令是什么， kbuectl get <资源名> 就对了。
如果你想看更多的信息，就可以指定 -o wide 参数，如下：
加上这个参数之后就可以看到资源的所在 ip 和所在节点 node 了。
记得加上 -n
-n 可以说是 kubectl get 命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在 get 命令后面加上 -n 。
kubectl get 命令可以列出 k8s 中的资源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 参数则可以指定 pod 所在的命名空间。
kubectl describe 命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情， 不过最常用的还是查看 pod 的详情 。他也同样可以使用 -n 参数指定资源所在的命名空间。
举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：
然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：
基本属性
其中几个比较常用的，例如 Node 、 labels 和 Controlled By 。通过 Node 你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过 labels 你可以检索到该 pod 的大致用途及定位。而通过 Controlled By ，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用 kubectl get <资源名> 来继续查找问题。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通过 kubectl get DaemonSet -n kube-system 来获取上一节资源的信息。
内部镜像信息
在中间部分你可以找到像下面一样的 Containers 段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如 Image 字段，当 pod 出现 ImagePullBackOff 错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。
事件
在 describe 查看详情的时候，最常用的信息获取处就是这个 Event 段落了，你可以在介绍内容的末尾找到它，如下：
是的，如果你看到上面这样，没有任何 Events 的话，就说明该 pod 一切正常。当 pod 的状态不是 Running 时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：
kubectl describe <资源名> <实例名> 可以查看一个资源的详细信息，最常用的还是比如 kubectl describe pod <pod名> -n <命名空间> 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到 Event 段落，其中记录着导致 pod 故障的原因。
如果你想查看一个 pod 的具体日志，就可以通过 kubectl logs <pod名> 来查看。注意，这个只能查看 pod 的日志。通过添加 -f 参数可以持续查看日志。例如，查看 kube-system 命名空间中某个 flannel pod 的日志，注意修改 pod 名称：
然后就可以看到如下输出：
如果你发现某个 pod 的服务有问题，但是状态还是显示 Running ，就可以使用 kubectl logs 来查看其详细日志。
在本篇文章里，我们了解了 k8s 的宗旨和一些基本概念，并知道了最为常用的 get 、 descibe 及 logs 命令，知道了这三条命令之后就几乎可以从 k8s 中获取所有常用信息了。接下来的 k8s 基本使用（下） 里，我们会更深一步，来了解 k8s 中如何创建、修改及删除资源。
本次使用5台centos7的服务器CRDL-242 A 10171242
CRDL-243 A 10171243
CRDL-244 A 10171244
CRDL-245 A 10171245
CRDL-246 A 10171246
安装 *** 作系统，使用ntp对时
配置epel-release 源
yum install -y epel-release
关闭防火墙，selinux
安装常用软件
yum install -y wget net-tools telnet tree nmap sysstat lrzsz dos2unix bind-utils ntp wget
yum install -y epel-release
一、在DNS242服务器上安装bind9
yum install -y bind
rpm -qa bind
二、修改配置文件
vi /etc/namedconf
13 listen-on port 53 { 10171242; }; # 监听本机IP
14 listen-on-v6 port 53 { ::1; }; # 删除，不监听IPV6
20 allow-query { any; }; # 允许所有主机查看
21 forwarders { 10171254; }; # 办公网上一级的DNS
33 recursion yes; # dns采用递归的查询
35 dnssec-enable no; # 关闭，节省资源（生产可能不需要关闭）
36 dnssec-validation no; # 关闭，节省资源，不做互联网认证
三、检查文件
[root@bind-server ~]# named-checkconf
[root@bind-server ~]# echo $
0
四、配置区域文件
vi /etc/namedrfc1912zones
# 最后添加
zone "hostcom" IN {
type master;
file "hostcomzone";
allow-update { 10171242; };
};
zone "odcom" IN {
type master;
file "odcomzone";
allow-update { 10171242; };
};
五、配置区域数据文件
vi /var/named/hostcomzone
$ORIGIN hostcom
$TTL 600 ; 10 minutes # 过期时间20191209+01序号
@ IN SOA dnshostcom dnsadminhostcom ( # 区域授权文件的开始，OSA记录，dnsadminhostcom为邮箱
2019120901 ; serial # 安装的当天时间
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dnshostcom # NS记录
$TTL 60 ; 1 minute
dns A 10171242 # A记录
CRDL-242 A 10171242
CRDL-243 A 10171243
CRDL-244 A 10171244
CRDL-245 A 10171245
CRDL-246 A 10171246
[root@bind-server ~]# vi /var/named/odcomzone
$ORIGIN odcom
$TTL 600 ; 10 minutes
@ IN SOA dnsodcom dnsadminodcom (
2019120901 ; serial
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dnsodcom
$TTL 60 ; 1 minute
dns A 10171242
五、检查配置文件
[root@bind-server ~]# named-checkconf
[root@bind-server ~]# echo $
0
六、检测配置文件
[root@bind-server ~]# named-checkzone "hostcom" /var/named/hostcomzone
zone hostcom/IN: loaded serial 2019120901
OK
[root@bind-server ~]#
[root@bind-server ~]# named-checkzone "odcom" /var/named/odcomzone
zone odcom/IN: loaded serial 2019120901
OK
[root@bind-server ~]#
七、更改文件的属组，权限
[root@bind-server ~]# chown root:named /var/named/hostcomzone
[root@bind-server ~]# chown root:named /var/named/odcomzone
[root@bind-server ~]# chmod 640 /var/named/hostcomzone
[root@bind-server ~]# chmod 640 /var/named/odcomzone
八、启动named
[root@bind-server ~]# systemctl restart named
[root@bind-server ~]# systemctl enable named
Created symlink from /etc/systemd/system/multi-usertargetwants/namedservice to /usr/lib/systemd/system/namedservice
[root@bind-server ~]#
九、查看启动端口
[root@bind-server ~]# netstat -luntp | grep 53
验证解析
[root@bind-server ~]# dig -t A CRDL-242hostcom @10171242 +short
10171242
[root@bind-server ~]#
添加短域名
[root@bind-server ~]# cat /etc/resolvconf
# Generated by NetworkManager
nameserver 10171242
search hostcom
精一门技术，学一门手艺！
Kubernetes 是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。
Kubernetes 简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes 首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。
Kubernetes 即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从 创建应用>应用部署>提供服务>动态伸缩>应用更新 一系列服务，提高了容器集群管理的便捷性。
大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。
但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：
如果我想要部署，以下几台机器：
如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。
并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务d性扩容机制也能够很好的应对突发流量。
Docker-Compose 是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去 *** 作，是非常耗费时间的，如果有了 Docker-Compose 只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose 只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。
Docker Swarm 是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose 单节点的缺陷， Docker Swarm 可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，
Kubernetes 它本身的角色定位是和 Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes 正在成为容器编排领域的领导者，其 可配置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。
在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种
打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。
Pod里面到底装的是什么？
具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。
pause容器：
Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的
一个Pod中的应用容器共享同一个资源：
在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。
在 Kubernetes 中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service
Service 是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信
我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service 是通过 Label Selector 来进行定义的。
使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。
Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行 *** 作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行 *** 作。
用户通过 Kubectl 提交一个创建 Replication Controller 请求，这个请求通过 API Server 写入 etcd 中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server 写到我们 etcd 里面
到下面，如果被 Scheduler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人 *** 心，然后通过 API Server 将这个结果也写到etcd中，随后，我们的 Node 上运行的小管家 Kubelet 进程通过 API Server 检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。
然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server 写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server 查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。
kube-proxy： 是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的
kubelet： 用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里
etcd： 用于持久化存储集群中所有的资源对象，API Server提供了 *** 作 etcd的封装接口API，这些API基本上都是对资源对象的 *** 作和监听资源变化的接口
API Server ： 提供资源对象的 *** 作入口，其他组件都需要通过它提供 *** 作的API来 *** 作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。
Scheduler ： 调度器，负责Pod在集群节点中的调度分配。
Controller Manager： 集群内部管理控制中心，主要是实现 Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由 Controller Manager 完成。
到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。
关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。
我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）