If you have a very tight deadline, use whatever framework the team is most familiar with. Trying to learn a new framework on a tight deadline is just asking for trouble.
Both frameworks can accommodate deadlines, but Scrum has the notion of time-boxing baked in. Kanban solves many of the same problems, but is not primarily concerned with deadlines or time boxes as first-class (or even second-class) concepts. If you have equal experience with both, then Scrum is often a more intuitive fit.
Comparing Approaches to Scheduling in Scrum and Kanban
Which process methodology (Scrum or Kanban) would you prefer for a project of tough deadline?
Neither framework is actually focused on deadlines. At a high level, Scrum is about negotiating scope, while Kanban is about negotiating cycle time. That isn't to say Scrum doesn't care about cadence, or that Kanban doesn't care about scope or time-boxing, but each one by itself tends to focus more on one than the other. That's why Scrum and Kanban are often used together in many agile shops: they're complementary approaches, not orthogonal ones.
With that said, if someone handed me a project with a very small number of iterations to complete it, I'd choose Scrum. That's not because things would get done faster or better with Scrum, but rather because the framework requires the Scrum Team (and especially the Product Owner) to continually ask "How much can we reliably deliver within the given time box?" Whether that time box is a single Sprint, or a time-boxed project with a hard deadline, the framework is designed for adding or trimming scope to meet short-term goals.
Kanban can do the same thing, really, but scope is less front-and-center in a methodology that's primarily focused on optimizing for flow. If you're a Kanban expert, you can adjust your queues and batch sizes to control cycle time and scope, but it's not an intuitive fit for time-boxing (which is what a deadline really is).
It's also worth mentioning that Scrum explicitly calls for a Sprint Goal, which is the central cohesion for each iteration. In contrast, Kanban isn't goal-oriented. While you can certainly queue work in Kanban in a way that expresses goals or evolving priorities, the system itself is really about continuous flow rather than focused, goal-oriented delivery.
In summary, you can use either method, or both together if you like. However, for time-boxed, goal-oriented work products I'd certainly consider Scrum a more natural fit.
How to Perform Agile Release Planning