I created a service that has a http server exposed on a port with k8 ClusterIP. Since all I need is to have another pod within the same cluster make requests to this service, I'm not exposing this service externally or over the internet. Currently, the requests made to this service is something like http://{service_name}.{namespace}.svc.cluster.local:8000 within the cluster - Is it secure enough? Does the requests need to be https to be fully secure (e.g. avoid sniffing traffic vulnerabilities)
This really does depend on your organisations attitude to risk. I believe there are two general views here:
Since this is an internal service using HTTPS to encrypt traffic in transit is not required. All of the systems that have access to the traffic are considered trustworthy.
It is always best to provide a layered security model and while this is an internal network encrypting the traffic in transit using HTTPS will ensure that a breach of the internal network (or misconfiguration) will have limited impact.
As I said at the start of the answer this depends on your organisations attitude towards risk and therefore the community cannot give you a yes/no answer. Here are some things that you can think about / discuss to get the correct answer for your specific deployment:
How sensitive is the data that is moving between the services. This will help you understand the impact of this data being disclosed inappropriately. Given the increase in attention that data protection gets these days I would suggest that if you have PII (Personally Identifiable Information) in this service then you should consider the impact high.
If the network / environment was compromised would the traffic between services give the attacker useful information. Essentially here I am considering here, if an attacker gains access is it worth their time to look at the traffic. Obviously if the attacker can gain access to the data at rest in an unencrypted form then there is no benefit to sniffing the traffic in transit.
What is the attack vector? Which systems would an attacker have to compromise to get access to the traffic? Essentially here we are looking at the likelihood of the system being compromised. This depends a lot on the architecture etc.
Costs - this is often the key points to an organisation what is the cost if it goes wrong? This depends on the data involved and the regulations that you are required to comply with. What is the cost of adding this layer of security?
Finally I will wrap up with my 2c worth, for communication between internal systems over HTTP I would strongly recommend using HTTPS. The overriding view I have is generally it is cheap from an engineering perspective to use HTTPS in place of HTTP from the start but more expensive to retro fit when you realise it is required. Using HTTPS gives additional security and shows that you are handling users data with care. Finally we have seen so many companies losing reputation over data being lost through not following common security methodologies think about how would you defend the decision in the event of a breach?