Hey there! I'm Nikhil Sihora

Objective To implement a conversational search of local available PDF documents using the OpenAI Langchain Framework and Python programming. Architecture Diagram System Requirements: Base Operating System (Windows / Linux / MacOS) DockerHub Login GitHub.com Login OpenAI API Secret Key Docker Desktop (Not required if working with Linux CLI) Setup Background: BaseOS: The host operating system were the complete tech stack described in architecture diagram will be running. Install Docker Desktop locally; Secure, out-of-the-box containerization software offering developers and teams a robust, hybrid toolkit to build, share, and run applications anywhere.

Network policies help control the flow of ingress and egress traffic to a group of pods (using label selectors). By default, every pod in the cluster can reach out to any other pod within the cluster. This means, there’s no network policy by default. There’s no need for a network policy to allow the response. If the request is allowed by the network policy, the response will be allowed automatically (stateful behavior).

Namespaces isolate resources within a Kubernetes cluster. Kubernetes creates a default namespace when the cluster is created. This default namespace is used to create resources. If the cluster is deployed using KubeAdmin, it also creates a namespace kube-system in which all the internal K8s resources are deployed. Resource limits can be placed at the namespace level. So, if we are using the same cluster for both dev and prod namespaces, we can place a resource limit on the dev namespace to prevent it from starving the prod namespace.

Kubernetes services enable communication between various components within and outside of the application. They enable loose coupling between micro-services in our application. Services are static IPs that can be attached to a pod or a group of pods using label selectors. They are not attached to deployments. Services prevent us from using the pod IP addresses for communication which could change when the pod is restarted. Lifecycle of pod and service are not connected.

Provides the capability to upgrade the instances seamlessly using rolling updates, rollback to previous versions seamlessly, undo, pause and resume changes as required. Abstraction over ReplicaSet. Blueprint for stateless pods (application layer). When a deployment is created, it automatically creates a ReplicaSet which in turn creates pods. If we run k get all we can see the resources created by deployment. Config YAML file 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 apiVersion: apps/v1 kind: Deployment metadata: name: httpd-frontend labels: name: frontend spec: replicas: 3 selector: matchLabels: name: frontend template: metadata: labels: name: frontend spec: containers: - name: httpd image: httpd:2.

ReplicaSet monitors and maintains the number of replicas of a given pod. It will automatically spawn a new pod if the pod goes down. It is needed even if we only have a single pod, because if that pod dies, replica set will spawn a new pod. It spans the entire cluster to spawn pods on any node. Tip ⛔ Newer and better way to manage replicated pods in Kubernetes than Replication Controllers Simple Config for a Replicaset 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 apiVersion: apps/v1 kind: ReplicaSet metadata: name: httpd-frontend labels: name: frontend spec: replicas: 3 selector: matchLabels: name: frontend template: metadata: labels: name: frontend spec: containers: - name: httpd image: httpd:2.