Congratulations, you've reached the end of this course on Kubernetes patterns for application developers. Let's review what we've learned. We began the course looking at multi-container patterns for pods. The lesson began with an explanation of why Kubernetes has pods and why they allow multiple containers. Then we saw how the sidecar pattern can be used to extend functionality of a primary container with a sidecar. This pattern is often used for shipping logs to central aggregation systems and to sync files with external systems. After that we learned about the ambassador pattern and how it can be used to proxy connections from a primary container to the outside world. The example we considered involved proxying connections to a database. Lastly, we looked at the adapter pattern and how it can provide a standardized view of an application. We implemented an adapter for a legacy application that wrote metrics in a non-standard form. We then became familiar with networking topics including a review of the basic networking principles in Kubernetes such as IP per pod, container local host communication and services to avoid the pitfalls of working directly with pod IP's. We then dove into more details on the different types of services that are available. They are cluster IP for internal only access, NodePort to open a port on each node for access to a service, load balancer to leverage a cloud providers load balancer to grant external access to Kubernetes service and external name to access services outside of the cluster using DNS CNAME records. We finished lesson by looking at network policy and how you can control access to groups of pods in a namespace. Remember that the policies don't have any effect if the clusters network plugin doesn't support network policy. Next, we learned about how service accounts provide an identity to pods running in the cluster. Service accounts are compatible with role based access control allowing pods to access communities API's when necessary. You can use the service account name field of a pod spec to configure a pod service account. We also learned the benefits of using service accounts to store image pull secrets when working with private container image registries. The previous lesson covered some tips on how to be productive with kube control. We saw how to use the completions command to enable shell completions for kube control. How do you get the filter output using labels and format output, how to use kube control to generate manifest files for a variety of resources and how to use kubectl to understand the resource fields. 

We certainly covered a lot of interesting topics for application developers working with Kubernetes but the fun doesn't end here. I'd encourage you to try out more of Kubernetes content here on Cloud Academy. There are several labs that give you hands on experience with Kubernetes clusters. The Kubernetes pod designed for application developers, Kubernetes observe ability and mastering Kubernetes pod configuration labs are all made specifically for application developers working with Kubernetes. The labs are a great place to practice and learn at the same time but keep on going after you completed them. Try things out on your own and try to solve some challenges you can think of. Think back to the leveraging kube control lesson to be as efficient and self-sufficient as possible. 

Lastly, please share your feedback so I can find out what you want to see more of and what you'd rather see less of and make content for you, and try to make it the best that it can be. 

Thank you for taking my course. Take what you've learned here and apply it and continue to expand your Kubernetes skills. Until next time, I'm Logan Rakai with Cloud Academy.