1) k8s makes a lot of sense for stateless applications (such as your website) but not so much for stateful applications that require a client to connect to the same container every time (there are ways to do it, but they are a pain in the ass.)
2) Tooling is getting better with time, but it's still pretty green. Packages for your usual orchestration tools like Puppet and Ansible are volunteer work so they get easily out of sync, or require more work than you'd expect to get going. Using their suggested YAML format leads to another problem: there's no easy way to keep secrets outside of the configuration files, unless you build your own process around it
3) Some pieces, like a replicated DB, might be easier to be kept outside of the k8s cluster. You can technically run them there, but they weren't designed for running in that kind of environment and sometimes it shows
4) The CI/CD story using Jenkins pipelines is far from solved. There are several packages that provide some solutions, but the documentation tends to be horrible and that leads to days of debugging through trial and error
5) Leaky abstractions everywhere. As an example, the Jenkins plugins to build using your k8s cluster suggests using the "credentials" system, but you need to add them manually after you boot the Jenkins service. Then your slaves stop receiving the credentials and you have to reboot Jenkins (I had to reboot it on average every 3 or 4 builds.)
Don't let that discourage you from using k8s as a "run" cluster, if your app is a shared-nothing, stateless app. It's so much easier to setup (specially on Azure and GCP) and it obviates the need for setting up Puppet + Sensu + load balancing just to make sure your service keeps running when a node dies.