scales independently • Reduces maintenance issues • uncouples components of your app - changes can be deployed without having to test entire codebase • reusable • usually a single developer or small team can create / manage • mixed language environment What are Microservices • generally REST APIs returning json • organized around function: a user service, crud for db app or a url shortening service • small units of an app but are standalone
(git) One codebase tracked in revision control, many deploys II. Dependencies (vendoring) Explicitly declare and isolate dependencies III. Config (docker) Store config in the environment IV. Backing services (docker/k8s) Treat backing services as attached resources V. Build, release, run (docker/k8s) Strictly separate build and run stages VI. Processes (docker/k8s) Execute the app as one or more stateless processes VII. Port binding (docker/k8s) Export services via port binding VIII. Concurrency (docker/k8s) Scale out via the process model IX. Disposability (docker) Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity (docker/k8s) Keep development, staging, and production as similar as possible XI. Logs (docker/k8s) Treat logs as event streams XII. Admin processes (k8s) Run admin/management tasks as one-off processes
scaled together • shared: ◦ Namespace ◦ Volumes ◦ IP • short life span - spin up and down quickly Services • defines a logical set of pods • defines access policy to pods • really a microservice • Targets pods by label selector • base unit for service discovery • More permanent than pods
• declarative updates for Pods and Replica Sets • describe the desired state • deployment controller will: ◦ change the actual state to the desired state ◦ Control rate of change ◦ Rollback to an earlier Deployment revision ◦ History ReplicaSets • the next-generation Replication Controller • works as part of a deployment • can be used standalone (but why?)
spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 create a deployment $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record deployment "nginx-deployment" created get deployment status $ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 18s get ReplicaSet Status $ kubectl get rs NAME DESIRED CURRENT AGE nginx-deployment-2035384211 3 3 18s
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment "nginx-deployment" image updated or edit the yaml (rollout) and $ kubectl edit deployment/nginx-deployment deployment "nginx-deployment" edited status of deployment (rollout) $ kubectl rollout status deployment/nginx-deployment deployment nginx-deployment successfully rolled out shows the status (new and old) $ kubectl get rs NAME DESIRED CURRENT AGE nginx-deployment-1564180365 3 3 6s nginx-deployment-2035384211 0 0 36s
kubectl rollout undo deployment/nginx-deployment deployment "nginx-deployment" rolled back roll back to a point in time! $ kubectl rollout undo deployment/nginx-deployment --to-revision=2 deployment "nginx-deployment" rolled back Note: Kubectl rolling update updates Pods and Replication Controllers in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have additional features, such as rolling back to any previous revision even after the rolling update is done.
defined in service ◦ connects directly to service ◦ layer 3 ◦ no SSL • GLBC k8s L7 Load balancer ◦ Still beta ◦ Layer 7 ◦ configure ingress objects ◦ does not clean up all network resources ◦ no SSL (?? ingress object) • GCP HTTP/HTTPS Load Balancer ◦ manual config ◦ SSL Certificate process?? • nginx ◦ defacto standard reverse proxy ◦ supports SSL ◦ layer 7 ◦ needs configuration ◦ easy to deploy • haproxy ◦ versatile L3,4,5,6,7 ◦ designed for network proxy ◦ what I use • many others