k8s简述
openstack用于管理虚拟机（计算、存储、管理），K8S用于管理容器，两者本身无联系，但可以把openstack管理的虚拟机看成容器，采用K8S管理。
K8s是kubernetes的缩写，8替换了中间的8个字母“ubernete”。
Kubernetes是一个跨主机集群的开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作，提供以容器为中心的基础架构。k8s的目标是构建一个软件和工具的生态系统，以减轻在公有云或私有云上运行应用程序的负担。
Kubernetes 项目由 Google 公司在 2014 年启动。Kubernetes 建立在 Google 公司超过十余年的运维经验基础之上，Google 所有的应用都运行在容器上, 再与社区中最好的想法和实践相结合，也许它是最受欢迎的容器平台。
Kubernetes 可以在物理或虚拟机集群上调度和运行应用程序容器。然而，Kubernetes 还允许开发人员从物理和虚拟机’脱离’，从以主机为中心的基础架构转移到以容器为中心的基础架构，这样可以提供容器固有的全部优点和益处。Kubernetes 提供了基础设施来构建一个真正以容器为中心的开发环境。
一． Kubernetes架构
Kubernetes包含三类组件（components）：master components、node components和addons。其中addons是插件，提供具体的功能和服务。master组件可以在集群中的任何节点上运行，然而为了简单起见，设置脚本通常会将所有master组件运行在同一个虚拟机上，并且不用在此虚拟机上运行用户容器。运行master组件的节点便被独立出来，称为Master节点，集群的其余节点称为工作节点Node。
1.1 Master组件
Kubernetes将集群中的机器划分为一个Master节点和一群工作节点（Node）。其中，Master节点上运行着集群管理相关的一组进程：etcd、kube-apiserver、kube-controller-manager、kube-scheduler、cloud-controller-manager，后四个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。
-
etcd
用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操作etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。
-
kube-apiserver
提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能。
1）提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
2）提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
3）资源配额控制的入口；
4）拥有完备的集群安全机制。
-
kube-controller-manager
集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作，比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的。
-
kube-scheduler
集群中的调度器，负责Pod在集群节点中的调度分配。
-
cloud-controller-manager
为底层云服务提供商提供支持，从v1.6引进，原来版本中k8s code依赖云服务提供商代码，被集成在kube-controller-manager中。本质就是循环调用cloud-provider-specific controllers，可通过启动kube-controller-manager时设置--cloud-provider为external关闭此特性。
1.2 Node组件
在每个Node上运行kubelet、kube-proxy、Container Runtime三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。
-
Kubelet
负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。注意kubelet不管理非k8s创建的容器。
-
Proxy
实现了Service的代理与软件模式的负载均衡器。
-
container Runtime
运行containers，k8s支持容器：Docker、containerd、cri-o、rktlet等实现k8s container Runtime Interface接口的容器。
1.3 Addons组件
Addons是pods和services，实现cluster特性。常用的插件有：DNS（每个clusters都应该有一个cluster DNS），Web UI（dashboard），Container Resource Monitoring，Cluster-level logging等等。
1.4 流程
通过Kubectl提交一个创建RC的请求，该请求通过API Server被写入etcd中，此时Controller Manager通过API Server的监听资源变化的接口监听到这个RC事件，分析之后，发现当前集群中还没有它所对应的Pod实例，于是根据RC里的Pod模板定义生成一个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的流量转发功能。
客户端通过Kubectl命令行工具或Kubectl Proxy来访问Kubernetes系统，在Kubernetes集群内部的客户端可以直接使用Kubectl命令管理集群。Kubectl Proxy是API Server的一个反向代理，在Kubernetes集群外部的客户端可以通过Kubernetes Proxy来访问API Server。
二． 核心概念
2.1 Node
Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。
Node包含的信息：
-
Node地址：主机的IP地址，或Node ID。
-
Node的运行状态：Pending、Running、Terminated三种状态。
-
Node Condition：…
-
Node系统容量：描述Node可用的系统资源，包括CPU、内存、最大可调度Pod数量等。
-
其他：内核版本号、Kubernetes版本等。
查看Node信息：
kubectl describe node
2.2 objects
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes用entities表征cluster状态。特别地，objects能描述：
-
What containerized applications are running (and on which nodes)
-
The resources available to those applications
-
The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
k8s对象是一条内容记录，一旦创建了对象，k8s会持续工作确保对象存在。可以通过Kubernetes API或kubectl命令行创建对象。
每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 spec 和 对象 status 。spec 是必需的，它描述了对象的 期望状态（Desired State） —— 希望对象所具有的特征。 status 描述了对象的 实际状态（Actual State） ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
.yaml文件用来描述k8s对象，传参给kubectl后，kubectl发起API请求将信息转换为JSON格式。一个.yaml示例：
apiVersion: apps/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
输出类似如下这样：
deployment "nginx-deployment" created
Kubernetes API Reference提供了所有可用对象的spec格式。可通过命令kubectl api-resources获取k8s支持的所有object。
2.3 Pod
Pod是一个逻辑概念，它是Kubernetes资源调度的单元，一般会把一组功能强相关的容器逻辑上称之为一个pod，Pod就是所说的实例。作为一个逻辑概念，pod本身没有资源，pod中的容器具有资源，创建pod，可以通过定义pod模块。
Pod包含一个或多个紧密相关的容器，一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”；一个Pod中的多个容器应用通常是紧密耦合的，Pod在Node上被创建、启动或者销毁；每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。
Pod里的多个业务容器共享Pause容器的IP，称为PodIP，同一个Pod里的容器之间仅需通过localhost就能互相通信。K8s要求底层网络支持集群中任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现，如Flannel、Openvswitch等，因此需要牢记：在k8s里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。
一个Pod中的应用容器共享同一组资源：
-
PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID；
-
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围；
-
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信；
-
UTS命名空间：Pod中的多个容器共享一个主机名；
-
Volumes（共享存储卷）：Pod中的各个容器可以访问在Pod级别定义的Volumes；
Pod的生命周期通过Replication Controller来管理；通过模板进行定义，然后分配到一个Node上运行，在Pod所包含容器运行结束后，Pod结束。
Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。
缺点: 不支持高并发, 高可用, 当Pod当机后无法自动恢复。
2.4 RC（Replication Controller）
ReplicationController（简称rc）是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。
RC中selector设置一个label，去关联pod的label，selector的label与pod的label相同，那么该pod就是该rc的一个实例；RC中Replicas设置副本数大小，系统根据该值维护pod的副本数。
Replicaset在继承Pod的所有特性的同时, 它可以利用预先创建好的模板定义副本数量并自动控制, 通过改变Pod副本数量实现Pod的扩容和缩容。
2.5 Service
在Kubernetes的世界里，虽然每个Pod都会被分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失，这就引出一个问题：如果有一组Pod组成一个集群来提供服务，那么如何来访问它呢？Service！
service是pod的路由代理抽象，用于解决pod之间的服务发现问题，即上下游pod之间使用的问题。传统部署方式中，实例所在的主机ip（或者dns名字）一般是不会改变的，但是pod的运行状态可动态变化(比如容器重启、切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。
一个Service可以看作一组提供相同服务的Pod的对外访问接口，Service作用于哪些Pod是通过Label Selector来定义的。
-
拥有一个指定的名字（比如my-mysql-server）；
-
拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号，销毁之前不会改变，只能内网访问；
-
能够提供某种远程服务能力；
-
被映射到了提供这种服务能力的一组容器应用上；
如果Service要提供外网服务，需指定公共IP和NodePort，或外部负载均衡器。
NodePort
系统会在Kubernetes集群中的每个Node上打开一个主机的真实端口，这样，能够访问Node的客户端就能通过这个端口访问到内部的Service了。
Kubernetes默认对外的NodePort限制范围为30000-32767, 这里如果要使用一些常用的端口(80，8080， 443)需将这个范围放大。
# vi /etc/kubernetes/manifests/kube-apiserver.yaml
在--service-cluster-ip-range与insecure-port间添加如下node port配置
- --service-cluster-ip-range=10.96.0.0/12 - --service-node-port-range=0-32767 - --insecure-port=0
EndPoint
Endpoint是可被访问的服务端点，即一个状态为running的pod，它是service访问的落点，只有service关联的pod才可能成为endpoint。
一个service示例：
apiVersion: v1 kind: Service metadata: name: demo spec: type: NodePort ports: - port: 80 nodePort: 80 selector: app: httpd-demo
Tip: 如果要对某一Pod或deployment添加对外访问端口, 这里service添加的selector的键值需与之相对应。
2.6 Deployment
Deployment在继承Pod和Replicaset的所有特性的同时, 它可以实现对template模板进行实时滚动更新并具备我们线上的Application life circle的特性。
使用kubectl edit -f deployment.yaml和kubectl apply -f deployment.yaml可以实时编辑配置从而达到扩容或缩容的效果。
2.7 Volume
Volume是Pod中能够被多个容器访问的共享目录。
2.8 Label
Label以key/value的形式附加到各种对象上，如Pod、Service、RC、Node等，以识别这些对象，管理关联关系等，如Service和Pod的关联关系。
2.9 DaemonSet
DaemonSet确保全部（或者部分）节点上运行一个pod的副本。当有节点加入集群时，也会为他们新增一个pod。当有节点从集群中移除时，这些pod也会被收回。
删除daemonSet将删除它创建的所有pod。
三. kubectl命令行工具
四． Kubernetes API
4.1 REST简述
REST（Representational State Transfer）只是为分布式超媒体系统设计的一种架构风格，而不是标准。基于Web的架构实际上就是各种规范的集合，这些规范共同组成了Web架构，比如HTTP、CS模式都是规范。每当我们在原有规范的基础上增加新的规范时，就会形成新的架构。而REST正是这样一种架构，它结合了一系列规范，形成了一种新的基于Web的架构风格。
传统的web应用大多是BS架构，涉及如下规范：1）客户-服务器；2）无状态性；3）缓存。REST才BS架构基础上增加了三个新规范：统一接口、分层系统和按需代码。
-
统一接口：REST架构风格的核心特征就是强调组件之间有一个统一的接口，表现为再REST世界里，网络上的所有事物都被抽象为资源，REST通过通用的连接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大地简化了系统，从而改善了系统的交互性和可重用性。
-
分层系统：分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，提高了系统的可伸缩性。
-
按需代码：REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码来扩展客户端的功能。但这在改善系统可扩展性的同时降低了可见性，所以只是REST的一个可选约束。
REST架构是针对Web应用而设计的，目的是为了降低开发的复杂性，提供系统的可伸缩性。REST提出如下设计准则：
-
网络上所有事物都被抽象为资源（resource）。
-
每个资源对应一个唯一的资源标识符（Resource identifier）。
-
通过通用的连接器接口对资源进行操作。
-
对资源的各种操作不会改变资源标识符。
-
所有的操作都是无状态的。
REST是基于HTTP的，所有对资源的操作行为都通过HTTP实现。HTTP把对一个资源的操作限制在4种方法内：GET、POST、PUT和DELETE。
REST之所以可以提高系统的可伸缩性，就是因为它要求所有操作都是无状态的。由于没有上下文的约束，做分布式和集群时更简单，也可以有效地利用缓冲池（Pool），并且由于服务器端不需要记录客户端的一系列访问，也就减少了服务器端的性能损耗。
4.2 K8S API概述
K8S API采用REST架构设计。k8s开发团队基于API级别选择版本而不是基于资源和域级别。
API资源使用REST模式，说明如下：
-
GET /<资源名的复数格式>：获取某一类型的资源列表。
-
POST /<资源名的复数格式>：创建一个资源，该资源来自用户提供的JSON对象。
-
GET /<资源名的复数格式>/<名字>：通过给出的名称获取单个资源。
-
DELETE /<资源名的复数格式>/<名字>：通过给出的名字删除单个资源。
-
PUT /<资源名的复数格式>/<名字>：功能通过给出的资源名和客户端提供的JSON对象来更新或创建资源。
-
PATCH /<资源名的复数格式>/<名字>：选择修改资源详细指定的域。
-
GET /watch/<资源名的复数格式>：随着时间变化，不断接受一连串的JSON对象，这些JSON对象记录了给定资源类别内所有资源对象的变化情况。
-
GET /watch/<资源名的复数格式>/<name>：随着时间变化，不断接受一连串的JSON对象，这些JSON对象记录了某个给定资源对象的变化情况。
其中，watch是k8s通过的“观察者”模式API接口，watch返回的是一连串JSON对象。
K8S API提供三种访问方式：
-
k8s API server通过一个名为kube-apiserver的进程提供服务，运行在master节点上。非安全端口（--insecure-port）8080，安全端口（--secure-port）6443提供服务。
-
如果只想对外暴露部分REST服务，可以在master或其他任何节点上通过运行kubectl Proxy进程启动一个内部代理。如在8001端口启动代理，并且拒绝客户端访问RC的API：
#kubectl proxy --reject-paths="^/api/v1/replicationcontrollers" --port=8001 --v=2
-
通过编程方式调用kubernetes API server。1）运行在Pod里的用户进程调用kubernetes API，通常用来实现分布式集群搭建的目标。2）开发基于kubernetes的管理平台，比如调用kubernetes API来完成Pod、Service、RC等资源对象的图形化创建和管理界面。可以使用kubernetes提供的Client Library。
api路径参考：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/
/api/v1/nodes
/api/v1/namespaces/{namespace}/pods
/api/v1/namespaces/{namespace}/services
4.3 k8s Proxy API
k8s API server最主要的REST接口是资源对象的增、删、改、查，此外还提供一类很特殊的REST接口--K8s Proxy API接口，这类接口的作用是代理REST请求，即K8s API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口上，由该kubelet进程负责响应。
node接口
/api/v1/proxy/nodes/{name}/pods/ #列出指定节点内所有Pod的信息
/api/v1/proxy/nodes/{name}/stats/ #列出指定节点内物理资源的统计信息
/api/v1/prxoy/nodes/{name}/spec/ #列出指定节点的概要信息
k8s pod接口
/api/v1/proxy/namespaces/{namespace}/pods/{name} #访问pod
/api/v1/proxy/namespaces/{namespace}/pods/{name}/{path:*} #访问pod的某个服务接口
作用：在k8s集群之外访问某个Pod容器的服务时，可以使用Proxy API实现，这种场景多用于管理目的。
k8s Service接口
/api/v1/proxy/namespaces/{namespace}/services/{name}
4.4 集群功能模块之间的通信
k8s API server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，通过API server提供的REST接口来实现，从而实现各模块之间的信息交互。
常见的一个交互场景是kubelet进程与API Server的交互。每个Node节点上的kubelet每隔一个时间周期，就会调用一次API server的REST接口报告自身状态，API server接收到这些信息后，将节点状态信息更新到etcd中。
五． YAML文件应用
当创建好一个k8s集群后，需要一个deployment，告诉k8s mater如何去创建应用，也可以更新应用。
Service 是一个抽象的概念，它定义了一组逻辑 Pods，并且提供访问它们的策略。
deployment和service等对象都可以通过kubectl或者YAML创建。先看一个YAML文件示例：
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-test spec: replicas: 1 template: metadata: labels: app: nginx spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx-test --- apiVersion: v1 kind: Service metadata: name: nginx-test spec: ports: - name: nginx-test port: 80 targetPort: 80 selector: app: nginx
可用如下命令应用此yaml文件并测试：
kubectl apply -f nginx-test.yaml kubectl get pods -o wide
也可以直接拷贝此文件到manifests目录/var/lib/rancher/k3s/server/manifests/下让k8s自动管理。
一般yaml文件会包含如下几个基本参数：
1）apiVersion：接口版本，现在一般都写v1，但它是随着安装Kubernetes和资源类型的变化而变化的。
2）kind：正在创建哪种对象object。如Pod，Deployment、Job、Ingress、Service等。
3）metadata：元数据，唯一确定对象，如名称、namespace、标签等。
4）spec：每种object对象的spec格式都不同，且包含嵌套域field。Kubernetes API Reference提供了所有可用对象的spec格式。如Pod，Deployment。可通过命令kubectl api-resources获取k8s支持的所有object。
六．kubeadm安装k8s集群
sudo kubeadm init --kubernetes-version=v1.14.1 [init] Using Kubernetes version: v1.14.1 [preflight] Running pre-flight checks [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/ [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 "etcd/ca" certificate and key [certs] Generating "etcd/server" certificate and key [certs] etcd/server serving cert is signed for DNS names [ubuntu-wang localhost] and IPs [192.168.134.144 127.0.0.1 ::1] [certs] Generating "etcd/peer" certificate and key [certs] etcd/peer serving cert is signed for DNS names [ubuntu-wang localhost] and IPs [192.168.134.144 127.0.0.1 ::1] [certs] Generating "etcd/healthcheck-client" certificate and key [certs] Generating "apiserver-etcd-client" certificate and key [certs] Generating "ca" certificate and key [certs] Generating "apiserver-kubelet-client" certificate and key [certs] Generating "apiserver" certificate and key [certs] apiserver serving cert is signed for DNS names [ubuntu-wang kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.134.144] [certs] Generating "front-proxy-ca" certificate and key [certs] Generating "front-proxy-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 18.010320 seconds [upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace [kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster [upload-certs] Skipping phase. Please see --experimental-upload-certs [mark-control-plane] Marking the node ubuntu-wang as control-plane by adding the label "node-role.kubernetes.io/master=''" [mark-control-plane] Marking the node ubuntu-wang as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule] [bootstrap-token] Using token: pu42jk.paf8g74hs9acbi19 [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster [bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace [addons] Applied essential addon: CoreDNS [addons] Applied essential addon: kube-proxy Your Kubernetes control-plane 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/ Then you can join any number of worker nodes by running the following on each as root: kubeadm join 192.168.134.144:6443 --token pu42jk.paf8g74hs9acbi19 \ --discovery-token-ca-cert-hash sha256:98f674ab4e52f10826d5c6ad0f67f73e5f377c6aa3044372234a0ed6114ebd9b
七. dashboard
dashboard
git官网https://github.com/kubernetes/dashboard,为k8s提供了一个管理UI。
7.1 安装dashboard
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
7.2 dashboard访问
认证方式有Kubeconfig和令牌两种方式，访问方式有四种：NodePort、APIServer、kubectl proxy、Ingress。
NodePort方式登录
修改kubernetes-dashboard.yaml的service的type为NodePort，nodePort可设为30000。
# ------------------- Dashboard Service ------------------- # kind: Service apiVersion: v1 metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kube-system spec: ports: - port: 443 targetPort: 8443 nodePort: 30000 selector: k8s-app: kubernetes-dashboard type: NodePort
kubectl get svc -n kube-system获取服务端口，直接访问端口：
此时有默认用户kubernetes-dashboard，权限为kubernetes-dashboard-minimal，访问受限。
可以创建一个高权限用户admin-user管理k8s，权限为cluster-admin：
$cat admin-user-sa-rbac.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system
创建完成后应用token：
$ kubectl apply -f admin-user-sa-rbac.yaml $ kubectl get pod -n kube-system|grep dashboard $ kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')
获取到token后用令牌方式登录。
kubeconfig登录
拷贝文件/etc/rancher/k3s/k3s.yaml，在最后加上token：***，下载到电脑本地。
八．k3s
k3s官网：https://k3s.io，github网站地址：https://github.com/rancher/k3s，目前github上提供不同平台的二进制文件；docker镜像网址：https://hub.docker.com/r/rancher/k3s/tags，提供不同平台的docker镜像。
启动master：（docker或containerd虚拟化方式，默认采用containerd）
k3s server --docker 或 k3s server --kube-apiserver-arg service-node-port-range=3000-60003
node加入集群：
k3s agent --docker -s https://192.168.134.140:6443 -t K1032decaad08cc4f82957538ae1c4008eb4587907dfb1930811e947bcf7c0b350d::node:c5989d78e810123f52a00ec00987d98b
注：应用中一定要将主机名加入到文件/etc/hosts中
# cat /etc/hosts 127.0.0.1 localhost 127.0.0.1 openwrt-adb4
k8s运行需要相关组件，k3s也以tar形式提供，名为k3s-airgap-images-$ARCH.tar，在启动pod前拷贝到/var/lib/rancher/k3s/agent/images目录下即可。
api访问：https://192.168.134.140:6443/api/v1/nodes
参考：
浙公网安备 33010602011771号