大致流程
1. Already got a running Kubernetes cluster
2. Deploy containerized applications on top of it
by create a Kubernetes deployment configuration
3. Check out and explore the application
4. Expose the app using service
5. Scale the app
6. Update the app
Learn to:
Deploy a containerized application on a cluster
Scale the deployment
Update the containerized application with a new software version
Debug the containerized application
A Kubernetes cluster consists of two types of resources:
The Master coordinates the cluste
Nodes are the workers that run applications
Start with commands:
kubectl cluster-info 查看集群信息
kubectl get pods
Pod: A group of one or more application containers that are relatively tightly coupled (such as Docker or rkt), and some shared resources like the following for those containers.
Shared storage, as Volumes | Networking, as a unique cluster IP address | Information about how to run each container, such as the container image version or specific ports to use
The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.
Pods are the atomic unit on the Kubernetes platform.
Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.
Deployment
A Deployment is responsible for creating and updating instances of your application
kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1--port=8080
Create a new deployment. kubernetes-boocamp is deployment name, image location (include the full repository url for images hosted outside Docker hub), and can specify a port.
can use --expose to create service atst
kubectl get deployments
The DESIRED state is showing the configured number of replicas
The CURRENT state show how many replicas are running now
The UP-TO-DATE is the number of replicas that were updated to match the desired (configured) state
The AVAILABLE state shows how many replicas are actually AVAILABLE to the users
kubectl get pods/services/deployments
kubectl describe - show detailed information about a resource
kubectl logs - print the logs from a container in a pod
kubectl exec - execute a command on a container in a pod
Node: A worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster by taking into account the available resources on each Node.
A pod always runs on a node
Every Kubernetes Node runs at least:
Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.
A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container, and running the application.
Node overview
Cluster
Explore
kubectl proxy: command to run a proxy in a second terminal window
Note: Check the top of the terminal. The proxy was run in a new tab (Terminal 2), and the recent commands were executed the original tab (Terminal 1). The proxy still runs in the second tab, and this allowed our curl command to work using localhost:8001.
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME
curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/
The url is the route to the API of the Pod.
kubectl exec $POD_NAME env -在容器级别运行命令，如列举环境变量(此处只有一个容器 故忽略了容器名)
kubectl exec -ti $POD_NAME bash -开启 bash session in the Pod’s container(忽略了容器名)
Expose
Service
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
kubectl describe services/kubernetes-bootcamp 可以看到node port
curl $(minikube ip):$NODE_PORT
kubectl describe deployment 部署会自动给pod生成label 可根据label找pod
kubectl get pods/services -l label
kubectl label pod $POD_NAME app=v1 给pod一个新label
kubectl delete services 之后集群外无法再访问到，但是app还在集群内运行
Service: An abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods.
A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects
Services can be exposed in different ways by specifying a type in the ServiceSpec:
ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
NodePort - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>. Superset of ClusterIP.
LoadBalancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
ExternalName - Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns.
More about the different types of Services:
https://kubernetes.io/docs/tutorials/services/source-ip/
https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/
Additionally, note that there are some use cases with Services that involve not defining selector in the spec. A Service created without selector will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using type: ExternalName.
Services match a set of Pods using labels and selectors
Labels are key/value pairs attached to objects and can be used in any number of ways:
Designate objects for development, test, and production
Embed version tags
Classify an object using tags
Services and labels
Scaling
kubectl scale deployments/kubernetes-bootcamp --replicas=4
get deployments 可看到变化
curl访问服务时 service会分流至不同的pod
Scaling is accomplished by changing the number of replicas in a Deployment
Note: Kubernetes also supports autoscaling of Pods, but it is outside of the scope of this tutorial
Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime
Update
Rolling updates allow the following actions:
Promote an application from one environment to another (via container image updates)
Rollback to previous versions
Continuous Integration and Continuous Delivery of applications with zero downtime
kubectl set image deployment/kubernetes-bootcamp image (followed by the deployment name and the new image version)
kubectl rollout undo deployments/kubernetes-bootcamp -roll back to our previously working version 上面set image 如果image不存在 可执行此命令
网友评论