说下K8S中的一些基础概念
首先是K8S中的一个概念,Deployment
如果想要在K8S中 ,进行一个创建一个单体应用
我们可以使用两种方式
Kubectl run nginx –image=nginx
kubectl create deployment my-nginx –image=nginx
两者的区别在于,对于run,其实创建的是一个pod
Create的则是一个deployment
我们在K8S中,通过发布Deployment,可以创建应用程序实例,放在一个Pod上,Pod则是K8S中最小的管理单元,之后会讲
创建完成Pod之后,Kubernetes Deployment Controller会持续监控这些实例,如果出现了实例故障,监视的Controller会将其再次调度并部署
因此,K8S的deployment具有自愈的功能
其次是Pod这个概念
K8S的一个抽象概念,存放一组container,以及container的共享资源,包括
共享存储,volumes
网络,每个Pod中具有一个唯一IP
所以,如果多个容器具有紧密耦合的关系,需要共享磁盘等资源,则应该部署在一个Pod中
除了Pod和Node之外,Kubernetes还有者一个核心的概念,即为namespace
是一种虚拟的概念,和实际存在的Node不同,是方便用户管理Pod或者Deployment的一种虚拟概念
之后是Kubenetes的一些基本操作
简单的是 get 命令,用于获取不同的资源类型
比如 kubectl get deployments
Kubectl get pods
Kubectl get nodes
其中可以添加的后缀有
Kubectl get deployments -A 获取所有空间的
Kubectl get deployments –all-namespace
kubectl get deployments -n kube-system
’
对于get可以获得资源
可以利用kubectl api-resources
可以加的后缀是–namespaced=true来进行查看
kubectl api-resources –namespaced=true
kubectl describe 获取资源的详细信息
kubectl describe deployment my-nginx
kubectl describe pod nginx-XXXXXX
kubectl logs Pod
kubectl logs -f nginx -pod-xxxx
查看对应的Pod的输出日志
以及kubectl exec 类似docker的exec命令
Kubectl exec Pod名称
Kubectl exec -it nginx-pod-xxx /bin.bash
用于进入一个Pod之中
之后我们将会讲解一下Kubernetes如何进行应用的抽象和封装
在此之前,我们先说其中一个重要的命令
Scale命令
首先是 –replicas 说明要指定包含多少个Pod
之后指定资源类别
kubectl scale –replicas=3 deployment tomcat6
然后是Kubernetes的应用暴露概念
我们可以将一个deployment中生命包含多个相同
然后,暴露一个统一的对外入口,然后由K8S来负责进行实际的跳转交付
这一点利用的命令是expose,例如
kubectl expose deployment tomcat6 –port=8912 –target-port=8080 –type=NodePort
其中,port是入口端口,负责用于暴露
Target-port是要跳转的目标Pod的端口
Type中可以指定clusterIp,暴露一个IP,负责进行负载均衡
这个IP范围,是我们在kubeadm init时候指定的网络范围
当选择type为 NodePort的时候,会暴露一个宿主机上的端口
比如我们 34303:8888
那么其实本质上一个Service 就是利用Label进行了管理
一个Service明白自己所需要管理的Pod对应的Label,然后利用不同的方式暴露自己的IP或者端口,然后进行相关的测试匹配
Service的选择是利用对应的选择器
[标签(Label)和选择器(Selector)](https://kubernetes.io/zh/docs/concepts/overview/working-
with-objects/labels)
然后我们展示一下K8S的滚动升级方式
滚动更新允许通过使用新的实例逐步更新 Pod 实例从而实现 Deployments 更新，停机时间为零
对应的代码为
Kubectl set image deployment.apps/tomcat6 tomcat=tomcat:jre8-alpine
#可以设置携带—record参数,记录变更
回滚升级
Kubectl rollout history deployment.app/tomcat6
回滚到指定版本
Kubectl rollout undo deployment.app/tomcat6 –to-revision=1
其实除了命令行使用K8S之外,K8S更加推荐使用声明式API
| apiVersion: apps/v1 #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment #该配置的类型，我们使用的是 Deployment metadata: #译名为元数据，即 Deployment 的一些基本属性和信息 name: nginx-deployment #Deployment 的名称 labels: #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解 app: nginx #为该Deployment设置key为app，value为nginx的标签 spec: #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用 replicas: 1 #使用该Deployment创建一个应用程序实例 selector: #标签选择器，与上面的标签共同作用，目前不需要理解 matchLabels: #选择包含标签app:nginx的资源 app: nginx template: #这是选择或创建的Pod的模板 metadata: #Pod的元数据 labels: #Pod的标签，上面的selector即选择包含标签app:nginx的Pod app: nginx spec: #期望Pod实现的功能（即在pod中部署） containers: #生成container，与docker中的container是同一种 – name: nginx #container的名称 image: nginx:1.7.9 #使用镜像nginx:1.7.9创建container，该container默认80端口可访问 |
接下来我们将这个yaml放在宿主机上,xxx.yaml,并进行应用
kubectl apply -f xxx.yaml
对于应用的暴露
只需要类似的命令式声明,在Service中的metadata中修改
| apiVersion: v1
kind: Service metadata: name: nginx-service #Service 的名称 labels: #Service 自己的标签 app: nginx #为该 Service 设置 key 为 app，value 为 nginx 的标签 spec: #这是关于该 Service 的定义，描述了 Service 如何选择 Pod，如何被访问 selector: #标签选择器 app: nginx #选择包含标签 app:nginx 的 Pod ports: – name: nginx-port #端口的名字 protocol: TCP #协议类型 TCP/UDP port: 80 #集群内的其他容器组可通过 80 端口访问 Service nodePort: 32600 #通过任意节点的 32600 端口访问 Service targetPort: 80 #将请求转发到匹配 Pod 的 80 端口 type: NodePort #Serive的类型，ClusterIP/NodePort/LoaderBalancer |
对于其他我们上述说的命令行操作,都可以在yaml中操作实现
比如扩缩容, 修改对应对象中的replicas即可
滚动升级也是
修改imageName属性等,也是kubectl apply -f xxx.yaml
之后部署dashboard
直接使用https://github.com/kubernetes/dashboard中的yaml部署即可
然后需要设置其中Service的暴露方式为 NodePort,方便使用
之后每次访问的时候需要输如令牌
kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user | awk ‘{print $1}’)
最后我们说下K8S中的kubectl和kubelet
kubeadm 负责安装的集群,后来是yum install etcd api-server
安装完成后,核心文件在于 /etc/Kubernetes,以Pod方式安装的核心组件
其中有,etcd api-server,scheduler等Pod的yaml文件
对于这些Pod,标记为集群的静态Pod,是不可以修改的