k8s基本操作
k8s基本操作
文章目录
一、k8s概念
1.1 、容器化部署
容器类似于 VM ,但是可以在应用程序之间共享操作系统。被认为是轻量级的。容器具有自己的文件系统、CPU 、内存、进程空间等。由于容器和基础架构分离,可以很方便的进行跨云和跨 Linux 发行版进行移植。
1.2、容器优势
- 解耦行
- 跨平台
- 可移植
- 隔离性
1.3、k8s功能
在生产环境中,我们需要管理运行应用程序的容器,并且确保这些容器不会停机。Kubernetes 可以提供了一个可弹性运行的分布式系统的框架,Kubernetes 可以满足我们的扩展要求、故障转移、部署模式等。
- 存储编排
- 自动部署与回滚
- 自我修复功能
- 服务发现
- 负载均衡
- 配置管理
1.4、k8s原理
二、k8s基本操作
命令 | 功能 | 用法 |
---|---|---|
create | 创建 | kubectl create -f xx.yaml |
edit | 编辑 | kubectl edit svc/nginx_service编辑名为nginx_service的svc |
get | 获取 | kubectl get pod |
patch | 更新 | kubectl patch -f xx.yaml |
delete | 删除 | kubectl delete-f xx.yaml |
expose | 暴露端口 | kubectl expose deployment nginx --port=8912 --target-port=80 --type=NodePort |
run | 创建 | kubectl run my-nginx --image=nginx:1.17.3 |
describe | 描述 | kubectl describe pod pod名 -n 命名空间名 |
logs | 日志 | kubectl logs -f Pod名称 -n 命名空间名 |
exec | 执行 | kubectl exec -it pod名 -n 命名空间 – /bin/bash |
rollout | 回滚 | kubectl rollout history deployment 应用部署名称; kubectl rollout undo deployment 应用部署名称 --to-revision=1 |
scale | 规模 | kubectl scale --replicas=数量 deployment 部署名称 |
apply | 应用 | kubectl apply-f xx.yaml |
2.1、namespace
Namespace是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的(默认是default),而node, persistentVolumes等则不属于任何namespace。
Namespace常用来隔离不同的用户,比如Kubernetes自带的服务一般运行在kube-system namespace中。
命令行直接创建
$ kubectl create namespace dev
文件创建
apiVersion: v1
kind: Namespace
metadata:
name: dev
2.2、pod
Pod是 Kubernetes 集群上的最基本的单元,同一个Pod中的应用可以共享磁盘,Pod 是一组容器(可包含一个或多个应用程序容器.
apiVersion: v1
kind: Pod
metadata:
name: redis
namespace: dev
spec:
containers:
- name: redis
image: redis
volumeMounts:
- name: redis-storage
mountPath: /data/redis
volumes:
- name: redis-storage
emptyDir: {}
2.3、deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义方法,用来替代以前的ReplicationController来方便的管理应用。可以通过定义Deployment来创建Pod和ReplicaSet滚动升级和回滚应用、扩容和缩容、暂停和继续Deployment。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: dev
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
2.4、service
Pod 是应用程序的载体,我们可以通过 Pod 的 IP 来访问应用程序,但是 Pod 的 IP 地址不是固定的,不方便直接采用 Pod 的 IP 对服务进行访问。 Service 会对提供同一个服务的多个 Pod 进行聚合,并且提供一个统一的入口地址,通过访问 Service 的入口地址就能访问到后面的 Pod 服务。
apiVersion: v1 # 版本
kind: Service # 类型
metadata: # 元数据
name: nginx_svc# 资源名称
namespace: dev# 命名空间
spec:
selector: # 标签选择器,用于确定当前Service代理那些Pod
app: nginx
type: NodePort # Service的类型,指定Service的访问方式
clusterIP: 80# 虚拟服务的IP地址
sessionAffinity: # session亲和性,支持ClientIP、None两个选项,默认值为None
ports: # 端口信息
- port:80 # Service端口
protocol: TCP # 协议
targetPort : 80 # Pod端口
nodePort: 30001# 主机端口
2.5、configMap
ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。
apiVersion: v1
kind: ConfigMap
metadata:
name: cm
namespace: dev
data:
# 类属性键;每一个键都映射到一个简单的值
how: very
type: charm
# 类文件键
config.yml: |
enemy.types=aliens,monsters
player.maximum-lives=5
---
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: dev
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: cm
key: how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: cm
key: type
volumeMounts:
- name: cm
mountPath: /data/#容器挂在路径
volumes:
- name: cm
configMap:
name: cm #将config.yml文件挂在容器的/data/目录下
restartPolicy: Never
2.6、pv和pvc
PV(Persistent Volume)是持久化卷的意思,是对底层的共享存储的一种抽象。一般情况下 PV 由 Kubernetes 管理员进行创建和配置,它和底层具体的共享存储技术有关,并通过插件完成和共享存储的对接。
PVC(Persistent Volume Claim)是持久化卷声明的意思,是用户对于存储需求的一种声明。换言之,PVC 其实就是用户向Kubernetes 系统发出的一种资源需求申请。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv_test
labels:
pv: pv_test
spec:
storageClassName: pv_test # 用于分组
capacity:
storage: 20m
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain #手动回收
nfs: # 使用 nfs 存储驱动
path: /data # nfs 共享的目录,mkdir -pv /nfs/data/20m
server: 192.168.70.129 # nfs 服务端的 IP 地址或 hostname
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc_test
namespace: dev
labels:
app: pvc_test
spec:
storageClassName: pv_test
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500m
selector:
matchLabels:
pv: pv_test
---
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: dev
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17.3
resources:
limits:
cpu: 200m
memory: 500Mi
requests:
cpu: 100m
memory: 200Mi
ports:
- containerPort: 80
name: http
volumeMounts:
- name: localtime
mountPath: /etc/localtime
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: localtime
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
- name: html
persistentVolumeClaim:
claimName: pvc_test
readOnly: false
restartPolicy: Always
PV 的生命周期
○ Available(可用):表示可用状态,还未被任何 PVC 绑定。
○ Bound(已绑定):表示 PV 已经被 PVC 绑定。
○ Released(已释放):表示 PVC 被删除,但是资源还没有被集群重新释放。
○ Failed(失败):表示该 PV 的自动回收失败。
PV 的访问模式:用来描述用户应用对存储资源的访问权限
○ ReadWriteOnce(RWO):读写权限,但是只能被单个节点挂载。
○ ReadOnlyMany(ROX):只读权限,可以被多个节点挂载。
○ ReadWriteMany(RWX):读写权限,可以被多个节点挂载。
2.7、ingress
通常情况下,service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。Service 可以使用 NodePort 暴露集群外访问端口,但是性能低、不安全并且端口的范围有限。Service 缺少七层(OSI 网络模型)的统一访问入口,负载均衡能力很低,不能做限流、验证非法用户、链路追踪等等。Ingress 公开了从集群外部到集群内 服务 的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。 使用 Ingress 作为整个集群统一的入口,配置 Ingress 规则转发到对应的 Service 。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
kubernetes.io/ingress.rule-mix: "true"
nginx.ingress.kubernetes.io/proxy-body-size: 50m
nginx.ingress.kubernetes.io/use-regex: "true"
name: test_ing
namespace: dev
spec:
tls:
- hosts:
- test.ingress.com
secretName: test.ingress.com
rules:
- host: test.ingress.com # 指定的监听的主机域名,相当于 nginx.conf 的 server { xxx }
http:# 指定路由规则
paths:
- path: /api # 匹配规则,Prefix 前缀匹配 it.nginx.com/* 都可以匹配到
backend: # 指定路由的后台服务的 service 名称
service:
name: nginx_svc # 服务名
port:
number: 80 # 服务端口
pathType: ImplementationSpecific
status:
loadBalancer:
ingress:
- ip: 192.168.120.1
- ip: 192.168.120.2
更多推荐
所有评论(0)