Skip to content

Essential tools and techniques for cloud-based development

Notifications You must be signed in to change notification settings

yanivnahoum/k8s-demo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

13 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Developing on Cloud Nine

We all know the advantages of developing locally. It's fast, it's easy, it's free. You can easily find the running apps and their logs, and debugging is a breeze. But the local development environment is not realistic because dependencies cannot be emulated like they can in the real world. There can be small or large differences from production environments. Additionally, all services have to be set up locally and kept in sync during production. This can potentially be a big burden for developers to handle as applications scale. Some services are impossible to run locally, like various types of data stores and queues provided as managed services by cloud vendors. Mocking or replicating cloud services or managed services in your local environment simply no longer translates to the real environment upon which your application will run during production. This means you are missing the chance to find potential sources of failures and not testing your applications in a realistic manner.

Using Helm & Kubectl Directly

Deploy

  • Deploy (in this case to local k8s cluster - docker-desktop): [greeting] helm upgrade --install greeting ./helm
  • Check rollout status: kubectl rollout status deployment greeting
  • Browse service: http://localhost:8088/greet/hello

Develop

  • Change greeting in GreetingController to "Shalom"
  • Build the app: [greeting] ./gradlew build -x check
  • Build docker images (1.0.0): [greeting] docker build -t k8s-demo/greeting:1.0.0 .
  • Deploy and check rollout status
  • Tail logs using kubetail: kt greeting
  • Browse service: http://localhost:8088/greet/hello

Debug

  • Use debug flag & reduce # of replicas to 1: [greeting] helm upgrade --install greeting ./helm --set replicas=1 --set debug=true
  • Run kubectl rollout status deployment greeting
  • port-forward local port 5005 to pod's 5005: kubectl port-forward greeting-<pod-hash> 5005
  • Launch debugger and put a breakpoint in the GreetingController, and hit http://localhost:8088/greet/hello
  • Clean up: revert replicas and debug: helm upgrade --install --reset-values greeting ./helm

Develop

Debug

  • Deploy greeting & reverse with helm
  • Check rollout status
  • Present the reverse-service by browsing http://localhost:8088/greet/hello?name=World&reversed=true
  • Run kubectl get svc reverse-service and show that this is a ClusterIP service, inaccessible from outside
  • curl http://reverse-service.default/reverse/hello fails
  • Run telepresence connect
  • Run telepresence status
  • Telepresence allows us to access the services as if we're in the cluster: curl http://reverse-service.default/reverse/hello now succeeds. We need to add the .<namespace> to the service name when we're not inside a pod that belongs to a specific namespace.
  • Note: we can add any pod into our namespace and get the kube dns:
    • kubectl run curl -it --image=radial/busyboxplus:curl
    • In the shell, run: curl http://reverse-service/reverse/hello
    • How do we get the DNS suffix? Run cat /etc/resolv.conf
    • Clean-up: ctrl-c and then run kubectl delete pod curl

Cleanup

  • telepresence leave reverse
  • Refresh the browser (no "***")
  • To remove all Telepresence component (kubectl get all -n ambassador): Run telepresence uninstall --everything
  • telepresence quit

About

Essential tools and techniques for cloud-based development

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published