WEEK 6: ENTRY 1

Little did I know that a Kubernetes deployment project could have multiple clusters and namespaces. Perhaps, it was because I was all along working with one cluster, which also has one namespace since the genesis of my internship. Well, since I needed to make sure that my application has access to the Big Query API, I needed to use a different cluster and a namespace because my initial cluster does not have any big query data. Thus, my manager created a new cluster and namespace and gave me the names. Just like how I login the previous cluster, I also used the same command line to login to the new cluster. The only part of the command line I needed to change was the cluster name as well as the namespace name if I needed to use the pods in that namespace. In short, I now have two clusters: one is to access the Big query data and the only is used for my server application. 



Unlike how easy it was to navigate and use one cluster, it is much more complex when dealing with two clusters for me. Previously, I just needed one configuration in my git-lab-ci file and k8s yaml files. But now, I need to make sure that my k8s configurations are working for both clusters. And as a newbie in k8s, I did not understand the essence of the overlays directory of the k8s main folder. The overlays house both files for the different configurations of the different clusters. My manager had to explain this concept for me before I fully grasped it. And even after doing the distinctive configurations and pushing my code, my pipeline was failing for the newly added cluster. I checked the logs on my Putty CLI and found out that the MountPath was not recognizing the newly added cluster configuration. This was because the mountpath had only the path of the first cluster I created. Therefore, to resolve this issue, I variabilized the path to both points at the two clusters anytime they are called. 


Overall, it was a very different experience compared to working with only one cluster. I am now required to be more alert on what cluster I am login to and when I should login to a particular cluster. So too, because of my manager's reaction to how I was struggling to use and configure the new cluster, I was prompted to do a deep dive on k8s deployment and understanding how to use yaml files.  My previous experience with working with the first cluster eased the process; however, I should have done more research on working with multiple clusters prior to our session today. Therefore, I intend to be more alert and proactive by looking at the concept or tools I will be working on prior to working with them.

Comments

Post a Comment

Popular posts from this blog

WEEK 4: ENTRY 3

  Today at my internship, I was assigned the issue of troubleshooting why my GET request Golang code is unable to generate the data from my http server. Since it was a combination of k8s deployment and Golang go, it was trickier and harder than I envisioned. The k8s was mainly used to orchestrate the objects that are needed to generate keytab from my pods. After several debugging: comparing and contrast the referred file I used as a source code coupled with looking up the errors on Stack flow (suggested me to delete my deployment and redeployed), I was still unable to fix the issue. Partly was because I did not understand what the error message was pointing at. Thus, I had to consult a member of the k8s team, who figured out that my deployment.yaml file was missing some configurations that needed to generate my key-tab. Simply, I needed the key-tab in order to be able to make the HTTP Get Request get my desired data.   Although the recommended solution from my consultation wor...
Read more

WEEK 6: ENTRY 3

  At my internship today, I continued unmarshalling the Json data I got back from Big Query API. Having tried replicating the data on the Go playground and using the Go unmarshall function yesterday, I did develop a better understanding of the json structure. I used Go’s struct to do the unmarshalling. Unlike the json data I got from my query, the documentation’s json data does not have any schema metadata and so I thought the same approach would not work. Little did I know that the schema data can be ignored when unmarshalling json data and that you can only concentrate on the part of the Json you want to unmarshall. When I consulted my buddy, he hopped on a zoom call with me and we did pair programming. I was the driver while he was the navigator, basically explaining what we were doing because he has more knowledge on Go and Json data manipulation. Working with him gave me more skills and confidence in what I was doing. He helped in not just using the Go struct, but also in tryi...
Read more

WEEK 7: ENTRY 1

  It sometimes feels like we are not good enough when our tries don’t work. Well at my internship today, I worked on resolving the json unmarshalling issue I was stuck with last Friday. After several back-and-forth consultations with my buddy and manager, I finally got a better understanding of how they wanted me to present the data. Basically, the data should be in a simple json array that could be manipulated easier. This is because as the json comes in key:pair format, I would need to extract all the keys and use those keys to send an HTTPS request to Elasticsearch Rest API.  Even though the approach was well defined and clear to me, I still struggled to implement it using the Golang Struct and Maps. One of the obstacles I had was because after unmarshalling the json data, the output was in a Golang interface type, which was not iterable like say a slice. A Golang slice is the equivalent  of a python array. Therefore, to overcome that barrier, I created an empty slice ...
Read more