k8s 学习笔记

[root@k8s-master01 ~]# kubectl config view   # 查看系统的kubeconfig:kubectl config view 
apiVersion: v1
clusters:   #集群列表 
- cluster:
    certificate-authority-data: REDACTED  #认证集群的方式
    server: https://172.16.150.212:6443    #访问服务的APIserver的路径
  name: kubernetes #集群的名称
contexts: #上下文列表
- context:
    cluster: kubernetes  #访问kubernetes这个集群
    user: kubernetes-admin  #使用 kubernetes-admin账号
  name: kubernetes-admin@kubernetes #给定一个名称
current-context: kubernetes-admin@kubernetes #当前上下文，表示使用哪个账号访问哪个集群
kind: Config
preferences: {}
users:  #用户列表
- name: kubernetes-admin #用户名称
  user:
    client-certificate-data: REDACTED #客户端证书，用于与apiserver进行认证
    client-key-data: REDACTED #客户端私钥

不能更新已创建的 pod 的 service account

在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是　　把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。此种方式仅作用于名称空间当中。

 ======

kubectl get svc -n kube-system

 dig -t A hubmanager-svc.baaisys.svc.cluster.local. @10.233.0.3

 随便进入集群里的一个pod里，

cat /etc/resolv.conf，看到的dns服务ip也是上面查询的结果

 Node 、 Namespace 和 PersistentVolume 等资源，它们不属于任何名称空间，因此资源对象的名称必须全局唯一。

查看集群信息： kubectl cluster-info

Pod 是容器的集合，同一个 Pod 中的所有容器共享 IP 地址和 Port 空间，也就是说它们在一个 network namespace 中

Pod 是 Kubernetes 调度的最小单位，同一 Pod 中的容器始终被一起调度
当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器。

查看应用被映射到节点的哪个端口： kubectl get svc

查看副本数： kubectl get deployments

Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等

StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。

Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡。

Namespace 可以将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster，不同 Namespace 里的资源是完全隔离的。

kubeadm 用于初始化 Cluster。
kubelet 运行在 Cluster 所有节点上，负责启动 Pod 和容器
kubectl 是 Kubernetes 命令行工具。通过 kubectl 可以部署和管理应用，查看各种资源，创建、删除和更新各种组件。

service 接收到的请求是如何转发到 Pod 的呢？这就是 kube-proxy 要完成的工作。

kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，
kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。

kubelet 是唯一没有以容器形式运行的 Kubernetes 组件，它在 Ubuntu 中通过 Systemd 运行。

创建资源：kubectl apply -f nginx.yml

创建资源：
kubectl apply -f nginx.yml：
删除资源：
kubectl delete -f nginx.yml

给节点打标签：
kubectl label node k8s-node1 disktype=ssd
查询节点标签：
kubectl get node --show-labels
删除节点标签：
kubectl label node k8s-node1 disktype- - 即删除。

变相查看某个资源的yaml:
kubectl edit daemonset kube-proxy --namespace=kube-system

restartPolicy ：对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。

查看 Completed 状态的 Pod： --show-all
kubectl get pod --show-all

同时运行多个 Pod，提高 Job 的执行效率：可以通过 parallelism 实现

查看api-versions支持的版本：kubectl api-versions

重启 kubelet 服务：systemctl restart kubelet.service

Service 通过 label 来挑选 Pod。

pod的IP 只能被 Kubernetes Cluster 中的容器和节点访问

Cluster 的每一个节点都配置了相同的 iptables 规则，这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service

Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。

多个资源可以在一个 YAML 文件中定义，用 --- 分割

若容器中安装了nslookup，可以用 nslookup 查看 某个服务 的 DNS 的信息

 

 上图中，EXTERNAL-IP 为 nodes，表示可通过 Cluster 每个节点自身的 IP 访问 Service

 

 nodePort 是节点上监听的端口。
port 是 service 上监听的端口。
targetPort 是 Pod 监听的端口

滚动更新是一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。

kubectl apply -f tst.yml --record:--record 的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。
通过 kubectl rollout history deployment httpd 查看 revison 历史记录。

 

 回滚：kubectl rollout undo deployment httpd --to-revision=1

一个 emptyDir Volume 是 Host 上的一个空目录。
emptyDir Volume 对于容器来说是持久的，对于 Pod 则不是。
当 Pod 从节点删除时，Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在，则 Volume 不受影响。

PersistentVolume (PV) 是外部存储系统中的一块存储空间

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)
Kubernetes 会根据用户创建的PVC查找并提供满足条件的 PV。

删除PVC : kubectl delete pvc mypvc1

persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain – 需要管理员手工回收。
Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等

accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点

动态供给是通过 StorageClass 实现的，StorageClass 定义了如何创建 PV

通过yaml创建Secret时，数据必须是通过base64编码后的
对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。

无论是 Pod 的 IP 还是 Service 的 Cluster IP，它们只能在 Kubernetes 集群中可见，对集群之外的世界，这些 IP 都是私有的。