关于kubernetes:k8s从入门到精通持续更新中

40次阅读

共计 6938 个字符,预计需要花费 18 分钟才能阅读完成。

Kubernetes

产生背景

  • 一个利用运行所须要依赖的环境资源

    CPU 执行具体的指令
    内存 保留执行代码和长期变量
    磁盘 保留利用须要读取和写入的文件
    网卡 传输网络数据供给用拜访内部资源或被拜访
    ...
  • 利用部署

     过来形式: 部署在一台机器上,以一个过程的形式运行
    
    古代形式: 一个应用服务会用多个实例去撑持,以实现流量均摊和高可用
    
    云原生时代: 主动依据流量拜访和机器资源 治理应用服务 多实例载 
  • 要解决的问题

     资源调度, 即一个利用要部署在一群机器外面的那些机器上
    
    依据机器的残余资源来调度, 即 CPU 内存 利用拜访规定 域名 域名转发规定 

外围定义

  • 一个用来治理 跨机器的容器化的利用,提供利用部署、运维、扩大等性能的开源零碎
  • 容器化利用能够了解为一个镜像,蕴含应用服务自身和其依赖的环境资源,跨机器部署时可无需再反复下依赖的过程
  • 基于容器化技术,k8s 主动对应用服务进行 扩、缩容以实现 资源服务 的 最大化 治理调度

根本架构

  • master

     零碎的大脑
    外围服务: Kube-APIServer,Kube-Scheduler,Kube-Controller-Manager
    
    Kube-APIServer
    次要提供了 Kubernetes 零碎对外的接口,接口的模式是基于 HTTP 协定的。因为大部分状况下,咱们会在部署 Kubernetes 的时候采纳 HTTPS 的部署形式,所以这个接口真正应用的时候所采纳的就是 HTTPS 协定。咱们整个课程的大部分内容都是间接和这个服务进行交互。通过 Kubernetes 的 Go SDK 向这个服务发送申请进行资源的操作
    
    Kube-Scheduler
    如果说 Master 所在的机器是从内部看 Kubernetes 时的大脑,那么 Scheduler 服务就是从外部看 Kubernetes 时的大脑。咱们刚刚说到的对于利用部署相干的细节都是由 Scheduler 服务来思考的。例如:对于利用 CPU 和内存资源的需要来说,Scheduler 须要综合考量整体可用 CPU 和内存资源的状况以决定将利用部署到哪些 Nodes 下面;或者是对于软件或者硬件层面的策略限度的考量(比方某些利用须要 GPU 资源);另外还有一些诸如 CPU 亲和性相干的考量等等
    
    Kube-Controller-Manager
    刚刚说过,当咱们深刻到 Kubernetes 架构外部看时,Scheduler 服务是整个 Kubernetes 的大脑,那么 Controller-Manager 就是具体的执行者。这个 Controller-Manager 是一组 Controller 的汇合。这些 Controller 的次要工作是让 Kubernetes 的零碎状态达到冀望的零碎状态。所谓冀望的零碎状态,举个例子如冀望的利用所需的 CPU 配额和限额或者是实例部署的数量等等。当你发送 API 申请去创立、批改、删除利用资源的时候,所做的操作就是设置一个利用部署的期望值。而这些 Controller 就是一直地查看这些部署的实时状态让零碎达到利用所冀望的状态。在目前的 Kubernetes 的版本中,这组 Controller 别离为 Replication Controller,Endpoints Controller,Namespace Controller 和 ServiceAccount Controller。别离负责:利用数量的扩容和伸缩;集群服务和后端利用所在 Pod 之间的动静关系的保护;命名空间的治理和 ServiceAccount 的治理 
  • Nodes

    Kubelet
    次要工作是确保部署在下面的利用失常运行。这个失常运行也就是下面所说的让零碎达到冀望的状态。为了可能让零碎达到这个状态,那必定得从 Master 获取冀望的状态,而后再定时上报以后本人的状态,这样零碎能力理解全局的状况。Kubelet 和 Master 的交互也是通过 APIServer 进行的。Kubelet 通过一个称为 cAdvisor 的容器资源剖析工具来获取 Node 和容器的数据进行上报
    
    Kube-Proxy
    运行在 Nodes 下面的利用提供拜访的通明代理服务以及负载平衡服务。从原理上来讲,利用是运行在咱们上面会介绍到的 Pod 外面的。一个利用如果有多个实例,其实就是会有多个 Pod。Kubernetes 零碎提供了一个称之为 Service 的对象来为这组利用的 Pod 提供集群层面的拜访入口。那么当一个申请达到 Service 的时候,如何决定将申请转发给哪个 Pod 外面的服务去解决呢?当扩容或者缩容的时候,这种转发的策略如何随之发生变化呢?这些都是通过 Kube-Proxy 来实现的,Kube-Proxy 为 Service 提供了申请转发和负载平衡 

根本资源

# kind 启动 k8s 集群
kind create cluster --name kubernetes --config <your_config_file> 


# 查看以后零碎下存在的命名空间
kubectl get namespace 
# or
kubectl get ns

# 查看以后零碎下指定命名空间
kubectl get ns <ns_name>
# 以 json/yaml 格局输入
kubectl get ns <ns_name> -o json
kubectl get ns <ns_name> -o yaml
# 更敌对的形式
kubectl describe ns <ns_name>

# 查看所有命名空间外面的 Pod(一组容器的汇合,蕴含须要运行的应用服务)
kubectl get pod --all-namespaces
# or 指定命名空间
kubectl get pod --namespaces <spec_ns>

# 查看所有命名空间外面的 Service(帮助 Pod 对外提供 TCP/UDP 拜访服务)
kubectl get svc --all-namespaces
# or 指定命名空间
kubectl get svc --namespaces <spec_ns>

# 查看某命名空间下的 deployment(帮助 Pod 调度)
kubectl get deployment <your_deployment> -n <your_ns>

# 查看 secret(存储敏感信息的资源,诸如用户名明码、TOKEN、SSH KEYS、HTTPS 证书)
kubectl get secret
# or 指定 secret
kuebcgtl get secret <your_secret>

# 查看 ingress(提供 OSI 七层数据转发至 Service 资源对象的资源对象)
kubectl get ingress

# 获取所有命名空间下的 ServiceAccount
kubectl get sa --all-namespaces
# 创立本人的 sa
kubectl create sa <your_sa>

受权 ServiceAccount 拜访 K8s 资源

  • k8s 的访问控制模型

  • 设置鉴权

    # 1. 设置一个账号鉴权信息
    # 创立 sa
    $ kubectl create sa demo-admin                                                      
    serviceaccount/demo-admin created
    
    # kubectl config set-credentials <your_sa> --token <TokenOfSecret>
    ## <your_sa>:demo-admin
    $ kubectl describe sa demo-admin                                                   
    Name:                demo-admin
    Namespace:           default
    Labels:              <none>
    Annotations:         <none>
    Image pull secrets:  <none>
    Mountable secrets:   demo-admin-token-w67mg
    Tokens:              demo-admin-token-w67mg
    Events:              <none>
    ## 查看 demo-admin 对应的 Tokens
    $ kubectl describe secret demo-admin-token-w67mg                                    [15:38:43]
    Name:         demo-admin-token-w67mg
    Namespace:    default
    Labels:       <none>
    Annotations:  kubernetes.io/service-account.name: demo-admin
                  kubernetes.io/service-account.uid: c096777d-6ce8-454e-bd9d-0096d2149fa0
    
    Type:  kubernetes.io/service-account-token
    
    Data
    ====
    ca.crt:     1025 bytes
    namespace:  7 bytes
    token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNoaXlhbmxvdS1hZG1pbi10b2tlbi13NjdtZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzaGl5YW5sb3UtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjMDk2Nzc3ZC02Y2U4LTQ1NGUtYmQ5ZC0wMDk2ZDIxNDlmYTAiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzaGl5YW5sb3UtYWRtaW4ifQ.KM5SNVdIcz0YY3WkYM_B8FQYmwMfMpEY__Y4mo9qKG-0y70elty8m7JDA4-bhmPrUw7CYt_5ah1z8cEKh27rBPWqoBNR2W61QX5pylAW-5uiRAEBi-K_-Rx-C1B2Rwwi-vLH71nF5x9SWt7L61VtWfVk5r6MLo_B8UjXNHSkZZ5j2wRFWLw0e_Jv4Qh9xibhr2ldfK-NWJUJugFG2GczdZo5foS0BOgZOmYLX9v8ixCc1Tz2miqcCPto6YfTLakQ1wbA2Ae_psOt_uKPkx7IYdxXury9tRCaB5_OxkpXWQ8FTEGgXiP8iq4fTFh8fUGg3iqOn_j9VfUYqy8Ci4x9Pw
    ## 设置账号鉴权
    $ kubectl config set-credentials demo-admin --token eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNoaXlhbmxvdS1hZG1pbi10b2tlbi13NjdtZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzaGl5YW5sb3UtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjMDk2Nzc3ZC02Y2U4LTQ1NGUtYmQ5ZC0wMDk2ZDIxNDlmYTAiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzaGl5YW5sb3UtYWRtaW4ifQ.KM5SNVdIcz0YY3WkYM_B8FQYmwMfMpEY__Y4mo9qKG-0y70elty8m7JDA4-bhmPrUw7CYt_5ah1z8cEKh27rBPWqoBNR2W61QX5pylAW-5uiRAEBi-K_-Rx-C1B2Rwwi-vLH71nF5x9SWt7L61VtWfVk5r6MLo_B8UjXNHSkZZ5j2wRFWLw0e_Jv4Qh9xibhr2ldfK-NWJUJugFG2GczdZo5foS0BOgZOmYLX9v8ixCc1Tz2miqcCPto6YfTLakQ1wbA2Ae_psOt_uKPkx7IYdxXury9tRCaB5_OxkpXWQ8FTEGgXiP8iq4fTFh8fUGg3iqOn_j9VfUYqy8Ci4x9Pw
    User "demo-admin" set.
    # 2. 设置集群的访问信息
    # 集群的访问信息就是指 API 服务的地址和服务端的证书
    # 应用上面的命令将 Kubernetes 服务端证书保留到 /home/demo/ca.crt 文件中
    $ docker exec kubernetes-control-plane cat /etc/kubernetes/pki/ca.crt | tee /home/demo/ca.crt
    
    $ kubectl cluster-info                                                                   
    Kubernetes master is running at https://127.0.0.1:43522
    KubeDNS is running at https://127.0.0.1:43522/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
    To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
    $ kubectl config set-cluster k8s-learning \                                             
    > --server https://127.0.0.1:43522 \
    > --certificate-authority /home/demo/ca.crt \
    > --embed-certs=true
    Cluster "k8s-learning" set.
    
    # 3. 创立一个 Context,把集群信息和鉴权信息绑定在一起
    $ kubectl config set-context k8s-learning-ctx \                                          
    > --cluster k8s-learning \
    > --user demo-admin
    Context "k8s-learning-ctx" created.
    
    # 4. 应用这个创立的 Context
    $ kubectl config use-context k8s-learning-ctx                                            
    Switched to context "k8s-learning-ctx".
    # 查看 pod 资源报错,不慌,因为还没有受权
    $ kubectl get pods                                                                       
    Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo-admin" cannot list resource "pods" in API group ""in the namespace"default"
    
    # 先切回到 kubectl 默认的无鉴权的拜访模式下
    $ kubectl config use-context kind-kubernetes
  • 受权简介

    kubernetes 资源次要分两类: 操作系统层面和命名空间层面
    
    依据拜访资源的类别,拜访角色也相应分成
    ClusterRole(操作系统层面)
    Role(命名空间层面)
    
    命名空间层面的资源操作包含:
    create(创立资源)update(更新资源)delete(删除资源)patch(批改资源的字段)get(获取资源)list(获取资源列表)watch(监听资源)
  • 根本步骤

     创立 ServiceAccount
    创立 ClusterRole 或 Role,并相应指定资源操作
    创立 ClusterRoleBinding 或 RoleBinding,而后绑定 ServiceAccount
  • 演示

    # 1. 创立一个 Role,在这个 Role 中授予操作相干资源的权限
    $ kubectl create role demo-admin-role \
    --resource pod,service,deployment,secret,ingress \
    --verb create,update,delete,patch,get,list,watch
    
    # 2. 创立一个 RoleBinding,将这个 Role 和 ServiceAccount 绑定在一起
    kubectl create rolebinding demo-admin-role-binding \
    --role demo-admin-role \
    --serviceaccount default:shiyanlou-admin
    
    # 3. 切到 k8s-learning-ctx
    kubectl config use-context k8s-learning-ctx

正文完
 0