使用yaml文件手动创建一个pod:
apiVersion: v1 kind: Pod metadata: name: my-cmd spec: containers: - image: 192.168.80.84:5000/centos_cmd:v1 name: centos-cmd # 需要注意的是spec.containers中的name字段，这里的命名规则和pod的命名规则是一样的，也就是如果"my_cmd"则会报错 # 其次注意"Pod"的“P”要大写我们来看一下这样创建的pod的yaml文件：kubectl create -f my-cmd.yaml，我们可以通过kubectl get pod my-cmd -o yaml来查看一下该pod
[root@k8s-master01 centos]# kubectl get pod my-cmd -o yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: "2021-01-13T03:32:42Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:spec: f:containers: k:{"name":"my-cmd"}: .: {} f:image: {} f:imagePullPolicy: {} f:name: {} f:resources: {} f:terminationMessagePath: {} f:terminationMessagePolicy: {} f:dnsPolicy: {} f:enableServiceLinks: {} f:restartPolicy: {} f:schedulerName: {} f:securityContext: {} f:terminationGracePeriodSeconds: {} manager: kubectl-create # 这里的启动方式有所不同，因为我们是通过create的方式创建的pod operation: Update time: "2021-01-13T03:32:42Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:status: f:conditions: k:{"type":"ContainersReady"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":"Initialized"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":"Ready"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} f:containerStatuses: {} f:hostIP: {} f:phase: {} f:podIP: {} f:podIPs: .: {} k:{"ip":"10.40.0.4"}: .: {} f:ip: {} f:startTime: {} manager: kubelet operation: Update time: "2021-01-13T04:39:23Z" name: my-cmd namespace: default resourceVersion: "429073" uid: 15d9f4f2-1fc8-4595-a00e-f96f52038ef9 spec: containers: - image: 192.168.80.84:5000/centos_cmd:v1 imagePullPolicy: IfNotPresent name: my-cmd resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: default-token-s9dfj readOnly: true dnsPolicy: ClusterFirst enableServiceLinks: true nodeName: k8s-node02 preemptionPolicy: PreemptLowerPriority priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 30 tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 volumes: - name: default-token-s9dfj secret: defaultMode: 420 secretName: default-token-s9dfj status: conditions: - lastProbeTime: null lastTransitionTime: "2021-01-13T03:32:42Z" status: "True" type: Initialized - lastProbeTime: null lastTransitionTime: "2021-01-13T04:39:23Z" status: "True" type: Ready - lastProbeTime: null lastTransitionTime: "2021-01-13T04:39:23Z" status: "True" type: ContainersReady - lastProbeTime: null lastTransitionTime: "2021-01-13T03:32:42Z" status: "True" type: PodScheduled containerStatuses: - containerID: docker://d7fee9118b0d5d2ccaa346d4cd97130a9f744e9bf6ee1b1ae32dfa0e583c2b41 image: 192.168.80.84:5000/centos_cmd:v1 imageID: docker-pullable://192.168.80.84:5000/centos_cmd@sha256:948479967390e7a98979d4b98beec6dfa3fc92c6ce832ece882e8b1843e0779f lastState: terminated: containerID: docker://0e6a82fe9e50924b7254fe06f131e43f3f66d8007de5524e31af38c6abd05d51 exitCode: 0 finishedAt: "2021-01-13T04:39:21Z" reason: Completed startedAt: "2021-01-13T04:22:42Z" name: my-cmd ready: true restartCount: 4 started: true state: running: startedAt: "2021-01-13T04:39:22Z" hostIP: 192.168.80.83 phase: Running podIP: 10.40.0.4 podIPs: - ip: 10.40.0.4 qosClass: BestEffort startTime: "2021-01-13T03:32:42Z" # 对一个字段的含义不清楚的话，可以使用"kubectl explain"来查看某一字段的含义
将本地网络中的端口转发给pod中的端口
首先我们可以使用一个nginx镜像:
# 我已经先将nginx:alpine的镜像推到了本地仓库 关于alpine版本 早先的alpine版本的镜像还有这段注释，但是后来大多数都给删掉了，特此记录 ``` postgres:<version>-alpine This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general. This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images. To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar). ```