k8s学习笔记2
博客源k8s踩坑记录
https://www.cnblogs.com/cmt/p/12132386.html#!comments
参考
https://kuboard.cn/learning/k8s-intermediate/obj/names.html#names
1.
传统部署时代:早期,企业直接将应用程序部署在物理机上。由于物理机上不能为应用程序定义资源使用边界,我们也就很难合理地分配计算资源。
例如:如果多个应用程序运行在同一台物理机上,可能发生这样的情况:其中的一个应用程序消耗了大多数的计算资源,导致其他应用程序不能正常运行。
应对此问题的一种解决办法是,将每一个应用程序运行在不同的物理机上。然而,这种做法无法大规模实施,因为资源利用率很低,且企业维护更多物理机的成本昂贵。
虚拟化部署时代:针对上述问题,虚拟化技术应运而生。用户可以在单台物理机的CPU上运行多个虚拟机(Virtual Machine)。
虚拟化技术使得应用程序被虚拟机相互分隔开,限制了应用程序之间的非法访问,进而提供了一定程度的安全性。
虚拟化技术提高了物理机的资源利用率,可以更容易地安装或更新应用程序,降低了硬件成本,因此可以更好地规模化实施。
每一个虚拟机可以认为是被虚拟化的物理机之上的一台完整的机器,其中运行了一台机器的所有组件,包括虚拟机自身的操作系统。
容器化部署时代:容器与虚拟机类似,但是降低了隔离层级,共享了操作系统。因此,容器可以认为是轻量级的。
与虚拟机相似,每个容器拥有自己的文件系统、CPU、内存、进程空间等
运行应用程序所需要的资源都被容器包装,并和底层基础架构解耦
容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署
Master组件
kube-apiserver etcd kube-scheduler kube-controller-manager cloud-controller-manager #默认不安装
Node 组件
kubelet 运行在每个集群节点上的代理程序 确保Pod中的容器处于运行状态 kube-proxy 网络代理程序 Service使用其将链接路由到Pod 容器引擎 Docker 、containerd 、cri-o 、rktlet
Addons 使用 Kubernetes 资源(DaemonSet、Deployment等)实现集群的功能特性
DNS
Web UI
Kuboard
ContainerResource Monitoring
将容器的度量指标(metrics)记录在时间序列数据库中
Cluster-level Logging
# kubectl get 资源类型
#获取类型为Deployment的资源列表 kubectl get deployments #获取类型为Pod的资源列表 kubectl get pods #获取类型为Node的资源列表 kubectl get nodes
名称空间
在命令后增加 -A 或 --all-namespaces 可查看所有 名称空间中 的对象,使用参数 -n 可查看指定名称空间
kubectl get all kubectl get nodes -o wide kubectl describe node rancher81#查看节点详细信息 预留内存就是使用的内存 限制内存就是被限制的内存 #查看名称为nginx-XXXXXX的Pod的信息 kubectl describe pod nginx-XXXXXX #查看名称为nginx的Deployment的信息 kubectl describe deployment nginx kubectl logs -f -t nginx-pod-XXXXXXX --tail 20 #tail 20 最多20行 kubectl get 后可以跟的参数 pods nodes svc deployments rc,services -f pod.yaml -o json watch kubectl get pods -o wide #动态查看
1024 1000 #保留内存和cpu
2048 2000 #限制的内存和cpu
网络组件
Flannel被公认为是最简单的选择
Calico以其性能、灵活性而闻名 支持Istio
Weave网络
会增加相当多的网络开销,可以使用NaCl加密来为sleeve流量自动加密所有路由流量
Kubernetes 中的 Service(服务) 提供了这样的一个抽象层,它选择具备某些特征的 Pod(容器组)并为它们定义一个访问方式。
Service(服务)使 Pod(容器组)之间的相互依赖解耦(原本从一个 Pod 中访问另外一个 Pod,需要知道对方的 IP 地址)。
一个 Service(服务)选定哪些 Pod(容器组) 通常由 LabelSelector(标签选择器) 来决定。
从 master(apiserver)到Cluster存在着两条主要的通信路径:
apiserver 访问集群中每个节点上的 kubelet 进程
使用 apiserver 的 proxy 功能,从 apiserver 访问集群中的任意节点、Pod、Service
创建 kubectl create -f nginx.yaml 删除 kubectl delete -f nginx.yaml -f redis.yaml 替换 kubectl replace -f nginx.yaml 对比应用 kubectl diff -R -f configs/ kubectl apply -R -f configs/